[Gemm 0]

Есть плата на AT91RM9200, на ней поднят стек (uIP), операционной системы нет. Программа просто получает поток данных и кладет в SDRAM.

 

Скомпилировали программу под ИАРом и под gcc в Линухе. Скорость работы программы, скомпиленной под gcc в 3 (три!) раза выше, чем под ИАРом. Стабильность работы стека после gcc выше. В обоих проектах включены кэши.

 

Это нормально, когда так отличается скорость работы одной и той же проги, скомпиленной разными компилерами? Как "ускорить" код от ИАРа? Пробовал разные оптимизации - не помогает. Что может быть не настроено в ИАРе?...

[Paramedic 0]

Есть плата на AT91RM9200, на ней поднят стек (uIP), операционной системы нет. Программа просто получает поток данных и кладет в SDRAM.

 

Скомпилировали программу под ИАРом и под gcc в Линухе. Скорость работы программы, скомпиленной под gcc в 3 (три!) раза выше, чем под ИАРом. Стабильность работы стека после gcc выше. В обоих проектах включены кэши.

 

Это нормально, когда так отличается скорость работы одной и той же проги, скомпиленной разными компилерами? Как "ускорить" код от ИАРа? Пробовал разные оптимизации - не помогает. Что может быть не настроено в ИАРе?...

 

Простите за любопытство, просто тоже сейчас борюсь с производлительностью AT91RM9200, но на компилятор грешить даже мысли не было (теперь есть). А Вы под отладчиком работаете или нет?

[zltigo 0]

Стабильность работы стека после gcc выше.

:) Сначала стабильно работающую программу напишите, потом уже рассуждайте о качестве кода компиляторов.

[AlexandrY 3]

Абсурд.

Скорее всего GCC неправильно выполняет какие-то операции и вылетает из процедур не выполняя их до конца. Отсюда и гигантский прирост скорости.

Либо сам счетчик времени врет.

GCC однозначно хуже компилирует чем коммерческие компиляторы, а тем более IAR.

Но разрыв идет на проценты а не в разы.

 

Есть плата на AT91RM9200, на ней поднят стек (uIP), операционной системы нет. Программа просто получает поток данных и кладет в SDRAM.

 

Скомпилировали программу под ИАРом и под gcc в Линухе. Скорость работы программы, скомпиленной под gcc в 3 (три!) раза выше, чем под ИАРом. Стабильность работы стека после gcc выше. В обоих проектах включены кэши.

 

Это нормально, когда так отличается скорость работы одной и той же проги, скомпиленной разными компилерами? Как "ускорить" код от ИАРа? Пробовал разные оптимизации - не помогает. Что может быть не настроено в ИАРе?...

[VslavX 0]

Скомпилировали программу под ИАРом и под gcc в Линухе. Скорость работы программы, скомпиленной под gcc в 3 (три!) раза выше, чем под ИАРом. Стабильность работы стека после gcc выше. В обоих проектах включены кэши.

Это беспредметный разговор - версии GCC и IAR какие? Опции компиляции какие? Режимы ARM/Thumb?

IAR 4.1x имеет довольно много ошибок - в свое время регулярно на них наталкивались. Версии 4.3x значительно лучше, но один раз компилятор тоже "был пойман" на генерации не совсем требуемого кода. Текущий 4.41 вроде пока ни в чем плохом не замечен.

По опыту использования GCC 2.95, 3.1, 3.2 разных сборок под сygwin - некоторые проблемы есть, но все преодолимо, встроенный ассемблер у GCC считаю лучшим.

Очерь понравился MS EVC, но там ассемблер полностью в стиле MASM и много танцев с бубном для получения бинарника (в-основном, EVC заточен для написания приложений под WinCE).

Компилировалось несколько функций объемом 10-100 строк указанными компиляторами в режиме ARM - IAR впереди по компактности и скорости, но общие отличия действительно на уровне процентов, отнюдь не в разы.

[e-yes 0]

Могу дать уточнения по гэцэцэ, по версии IAR Gemm ответит.

GCC 4.2.0, arm-none-eabi, сборка от codesourcery. Оптимизация - O2.

единственное отличие в коде - используются "несколько иные" memcpy и memset - выдрал из ARM'овского порта mplayer'а (IAR не понимает код GAS'а, к сожалению). Правда копирования из памяти в память очень мало.

 

Измеряем "скорость" одним и тем же сниффером, так что точность есть:)

 

P.S. Надо бы еще 3.4.6 и 2.9.5 затестить:)

[Gemm 0]

:) Сначала стабильно работающую программу напишите, потом уже рассуждайте о качестве кода компиляторов.

А с чего вы взяли, что она не стабильно работающая?

 

Это беспредметный разговор - версии GCC и IAR какие?...

IAR 4.41A. Режим ARM. Оптимизация отключена.

 

Абсурд.

Скорее всего GCC неправильно выполняет какие-то операции и вылетает из процедур...

Да нет, вроде ничего не вылетает - корректное TCP соединение, корректные пакеты (смотрим снифером). Пингуется без ошибок. Только ГЦЦшная 0.19мс, а ИАРовская 0.3мс.

 

Простите за любопытство, просто тоже сейчас борюсь с производлительностью AT91RM9200, но на компилятор грешить даже мысли не было (теперь есть). А Вы под отладчиком работаете или нет?

Работаем в IAR, отлаживаемся в нем же через JLink. Может и не надо грешить на компиллеры - возможно ошибка в нашем коде.

 

 

Есть подозрение, что дата кэш не включился, тк прироста в скорости не обнаружил. Включаю так:

asm("MRC p15, 0, r0, c1, c0, 0");

asm("ORR r0, r0, #0x00000004");

asm("MCR p15, 0, r0, c1, c0, 0");

 

Еще используем разные memcpy. Та, которая в ИАРовской библиотеке довольно медленная. Переписал свою на асме, но там траблы с выравниванием... Может кто поможет со быстрой стабильной memcpy и memset?

[Paramedic 0]

Есть подозрение, что дата кэш не включился, тк прироста в скорости не обнаружил. Включаю так:

asm("MRC p15, 0, r0, c1, c0, 0");

asm("ORR r0, r0, #0x00000004");

asm("MCR p15, 0, r0, c1, c0, 0");

 

Я для включения дата кэша использую библиотечные функции:

//*----------------------------------------------------------------------------

//* \fn AT91F_EnableDCache

//* \brief Enable D Cache

//*----------------------------------------------------------------------------

void AT91F_EnableDCache(void)

{

unsigned int ctl;

 

ctl = AT91F_ARM_ReadControl();

ctl |= (1 << 2);

AT91F_ARM_WriteControl(ctl);

}

 

//*----------------------------------------------------------------------------

//* \fn AT91F_ARM_ReadControl

//* \brief Read Control register

//*----------------------------------------------------------------------------

inline unsigned int AT91F_ARM_ReadControl()

{

register unsigned int ctl;

asm("MRC p15, 0, r0, c1, c0, 0");

return ctl;

}

 

//*----------------------------------------------------------------------------

//* \fn AT91F_ARM_WriteControl

//* \brief Write Control register

//*----------------------------------------------------------------------------

inline void AT91F_ARM_WriteControl(unsigned int ctl)

{

asm("MCR p15,0,r0,c1,c0,0");

}

[VslavX 0]

IAR 4.41A. Режим ARM. Оптимизация отключена.

Тады ничего сказать не могу - без оптимизации IAR пускать не пробовал.

Есть подозрение, что дата кэш не включился, тк прироста в скорости не обнаружил. Включаю так:

asm("MRC p15, 0, r0, c1, c0, 0");

asm("ORR r0, r0, #0x00000004");

asm("MCR p15, 0, r0, c1, c0, 0");

Хм, а разве на девятых ARM-ах кеш данных без включенного MMU работает? Помнится, там еще прилично кода по инициализации MMU требуется.

[Paramedic 0]

Только ГЦЦшная 0.19мс, а ИАРовская 0.3мс.

 

Ну это не в три раза и даже не в два.

С отключенной оптимизацией в ИАРе код заметно медленне исполняется.

[Gemm 0]

Ну это не в три раза и даже не в два.

С отключенной оптимизацией в ИАРе код заметно медленне исполняется.

Пробовал с оптимизациями - то же самое. Это только в пингах такая разница. В нормальном TCP обмене именно в 3 раза. Если не правильно включили дата кэш, то это неправильное включение - под обоими компиллерами.

[zhz 0]

Еще используем разные memcpy. Та, которая в ИАРовской библиотеке довольно медленная. Переписал свою на асме, но там траблы с выравниванием... Может кто поможет со быстрой стабильной memcpy и memset?

Вот это: http://research.microsoft.com/invisible/sr.../_memfunc.s.htm

я подрихтовал немного под IAR: memfunc.rar

[zltigo 0]

А с чего вы взяли, что она не стабильно работающая?

Да, однако, с Ваших-же слов:

Стабильность работы стека после gcc выше.

 

 

я подрихтовал немного под IAR: memfunc.rar

Да уж - глянул исходники IAR ( правда IAR 4.20 ) не ожидал такого тупого побайтового копирования увидеть.

Однозначно надо пользовать разумный вариант с пословным копированием.

 

Хотя в узких местах я традиционно с АРМ работаю с буферами выровненными на слово и размерами пакетов кратными слову. Затраты памяти не слишком велики а с быстродействием полегче.

 

P.S.

В приложении альтернативный приличный сишный вариант memcpy()

memcpy.rar

Изменено 26 июня, 2007 пользователем zltigo

[e-yes 0]

zltigo, читайте это так: при компиляции gcc (как ARM, так и x86) программа работает стабильно. При компиляции IAR'ом - стабильно не работает.

[zltigo 0]

zltigo, читайте это так: при компиляции gcc (как ARM, так и x86) программа работает стабильно. При компиляции IAR'ом - стабильно не работает.

Ну я так примерно и прочитал. И посоветовал сначала добиться работоспособности.