[repstosw 18]

Quote

Кто тестировал IAR ARM 8.50, отзовитесь

 

Использовал только 8.40, которая доступна для скачивания. Сделал 30 дней пробы с полными возможностями.

Строил проект под Cortex-A8, состоящий около 50 000 строчек кода на С/C++.  Это 600 - 700 кБ чистого ARM-кода (без данных!)

 

Результат не порадовал, но и не огорчил.

 

На максимальной оптимизации по скорости даёт глючный нерабочий код. Если выставить "Balanced", то код работает.  Если сделать "Speed" отдельным модулям - отрисовка пикселей, графические фильтры ит.п., а остальному коду "Balanced", то итоговая скорость работы приложения становится равной  скорости варианта того же проекта, скомпилированного тулчейном GCC (gcc-arm-none-eabi v.9 за 25 май).

 

Тоесть иными словами, GCC собирает код  с такой же скоростью и бесплатно.  Возникает вопрос "нафига мне IAR ?"

 

При этом GCC собирает на -Ofast весь проект и он полностью рабочий и не глючит (в отличие от IAR, когда оптимизация "Maximum", "Speed", enable vectorize).

 

Скорее всего, моя голова выполнила всю работу за компилятор, так как оптимизацию узких мест я сделал вручную на уровне Си как мог.

 

В программе делаются следующие вещи:  5 слоёв графики 400x240, фильтр 2xSaI раздувающий кадр до 800x480,  звук декод CELT 1 канал + 12 каналов WAV PCM,  расчёт физики Box2D,  логика приложения на C++, разжатие данны по алгоритму ZLIB и многое другое.

 

Итог:  450 кадров в секунду без фильтра и 110 кадров в секунду с фильтром.

 

P.S. Попутно затестировал armclang v.6 всё для того же Cortex-A8.  Результаты огорчили - фильтр 2xSaI 800x480 16 bpp жевал с меньшей скоростью, чем тот же вариант программы фильтра на GCC.

В листингах armcc вижу упоминание про GNU-секции, что как-бы намекает на то, что ARMCLANG - переделыш GCC, за который ещё и просят деньги.  Наверное сейчас модно - взять проект с GPL-лицензией и превратить его в проприетарщину.  Подозреваю, компиляторы они с нуля не пишут свой, а бирут готовый и продают.  По мне это верх наглости.

 

На счёт товарищей из IAR Systems не знаю, но полагаю, что свой компилятор они также родили с GCC

 

Ну и самое главное, - где вы брали IAR 8.5, когда на офсайте доступна только v. 8.4 ?

 

 

 

Изменено 7 июня, 2020 пользователем repstosw

[VladislavS 39]

1 час назад, __inline__ сказал:

Ну и самое главное, - где вы брали IAR 8.5, когда на офсайте доступна только v. 8.4 ?

 

Как так? 8.50 17.02.2020 релизнут. А сейчас на оффсайте 8.50.4 раздают. http://netstorage.iar.com/SuppDB/Protected/PRODUPD/014675/EWARM-CD-8504-26143.exe

 

Проблема GCC в том, что его из "взрослого" компилятора "натягивают" на микроконтроллеры. И не до конца натягивают. Например, GCC не умеет RBIT делать на ARM. Очень не хватает мне человеческих листингов, чтобы С и ASM вместе был.

 

IAR же наоборот из компилятора для микроконтроллеров старается "большим" стать. С переменным успехом.

 

ARMCC v6 хорОш, но сыроват. Последний словленый мной его выкрутас - на максимальной оптимизации они умудрились HardFault по невыровненному доступу на ядре Cortex-M4 (оно поддерживает невыровненный доступ) устроить. Профи, ничего не скажешь :)

[jcxz 222]

1 час назад, __inline__ сказал:

На максимальной оптимизации по скорости даёт глючный нерабочий код. Если выставить "Balanced", то код работает.

С вероятностью 99% это говорит о наличии багов в компилируемом ПО.

1 час назад, __inline__ сказал:

При этом GCC собирает на -Ofast весь проект и он полностью рабочий и не глючит (в отличие от IAR, когда оптимизация "Maximum", "Speed", enable vectorize).

Так значит IAR-у нужно сказать спасибо, что он выявил баги в вашей программе.  А с GCC они сразу не вылезли, стрельнут потом.  

1 час назад, __inline__ сказал:

Ну и самое главное, - где вы брали IAR 8.5, когда на офсайте доступна только v. 8.4 ?

Ну и главное - где Вы там нашли 8.40? Везде где не тыкал там - 8.50 не меньше.  

[one_eight_seven 6]

10 minutes ago, jcxz said:

Так значит IAR-у нужно сказать спасибо, что он выявил баги в вашей программе.  А с GCC они сразу не вылезли, стрельнут потом.  

Это если он выдал Warning'и. Иначе, "IAR не сумел нормально произвести оптимизацию",- не менее вероятное событие.

Изменено 7 июня, 2020 пользователем one_eight_seven

[VladislavS 39]

3 минуты назад, jcxz сказал:

С вероятностью 99% это говорит о наличии багов в компилируемом ПО.

Согласен. Просто не хотел коллегу расстраивать. Мой опыт говорит, что из-под IAR "более рабочий" код обычно выходит, он больше прощает. Например, не оптимизирует доступ к памяти по указателю, если вдруг volatile забыть. Или принимает за constexpr адреса, что противоречит стандарту, но де факто удобно и работает. 

Я в последнее время стал свои проекты разными компиляторами собирать. Вместе они больше проблем в коде находят :)

[jcxz 222]

1 минуту назад, one_eight_seven сказал:

Это если он выдал Warning'и.

Это был юмор (смайл). А вообще - если судьба (или компилятор) приводит к тому, что при какой-то комбинации опций компиляции/оптимизации (допустимых ессно), результат становится нерабочим, то нужно благодарить её (судьбу) за выявленный потенциальный баг. Постараться зафиксировать условия его проявления (добиться воспроизводимости) и.... искать его (баг)!

А не пытаться "замести под ковёр", меняя опции компилятора или компилятор.

[one_eight_seven 6]

4 minutes ago, jcxz said:

Постараться зафиксировать условия его проявления (добиться воспроизводимости) и.... искать его (баг)!

Не всегда. У меня есть живой пример, не относящийся к IAR/GCC, а относящийся к  симуляции SystemVerilog. Xcelium от Cadence не умеет нормально рандомизировать вообще, но недавно они улучшили рандомизатор, и он стал уметь ещё меньше, и мне пришлось переписывать рандомизацию. Т.е. сломался код, который соответствовал стандарту и работал в старых версиях.

При этом, этот же код (старый, до переделки) работает в VCS от Synopsis и в Questa от Mentor Graphics. Переделанный код работает во всех трёх симуляторах, но он, по сравнению со старым - это как переход на ассемблер после C++.

Изменено 7 июня, 2020 пользователем one_eight_seven

[VladislavS 39]

3 минуты назад, one_eight_seven сказал:

и он стал уметь ещё меньше

Это другой случай. Компилятор же не сделал молча нерабочий код?

[one_eight_seven 6]

10 minutes ago, VladislavS said:

Я в последнее время стал свои проекты разными компиляторами собирать. Вместе они больше проблем в коде находят :)

Линт и статический анализ используете?

Just now, VladislavS said:

Это другой случай. Компилятор же не сделал молча нерабочий код?

сделал. Скомпилировал и слинковал молча, без предупреждений и ошибок. Всегда довожу количество Warning'ов нуля, где это возможно. В случае с тем же каденсом - это невозможно, поскольку он выдаёт Warning об использовании семантики, соотвествующей новой версии стандарта - такое приходится отключать.

Изменено 7 июня, 2020 пользователем one_eight_seven

[VladislavS 39]

1 минуту назад, one_eight_seven сказал:

Линт и статический анализ используете?

Это другое. Безупречный с точки зрения стандарта языка код может легко в железе "чудеса" творить. Никогда ты ими не отловишь HardFault по невыровненному доступу, особенно на ядре, в котором его не может быть по определению.

[repstosw 18]

13 minutes ago, jcxz said:

Это был юмор (смайл). А вообще - если судьба (или компилятор) приводит к тому, что при какой-то комбинации опций компиляции/оптимизации (допустимых ессно), результат становится нерабочим, то нужно благодарить её (судьбу) за выявленный потенциальный баг. Постараться зафиксировать условия его проявления (добиться воспроизводимости) и.... искать его (баг)!

А не пытаться "замести под ковёр", меняя опции компилятора или компилятор.

 

Ну это довольно легко вычислить, повышая уровень оптимизации отдельным библиотекам до выявления бага.

 

Только тут больше роли играет вопрос преемственности неких оптимизаций.  Поясню. Например, есть физический движок Box2D. Он сделан на floating point.  Но неизвестно, как он себя будет вести, если арифметику с плавучкой вести в "relaxed mode".  Может он будет корректно работать только в "strict mode".   Это только со временем выявляется, так как не всегда возможно воспроизвести баги с физдвижком (например, когда объекты проваливаются сквозь пол).

 

Ну и то же руководство по сборке gentoo linux, не рекомендует собирать его с опциями выше, чем -O2.  Потому что разработчики ядра не гарантируют работоспособность ядра на -O3 и -Ofast.

Выходит, по-вашему,  ядро тоже бажное?  Я не отрицаю этого, так как баги программ накапливаются с ростом объёма кода, поэтому полностью избавиться от них крайне сложно.

Но есть тенденция, что у GCC больше шансов сделать код рабочим на -O3 или fast, чем у IAR.

 

 P.S.  Из ворнингов только неявный типкаст float в int (это нормально, при растеризации и получения целых конечных координат на экране), много неиспользуемых переменных.

 

Изменено 7 июня, 2020 пользователем repstosw

[jcxz 222]

2 минуты назад, VladislavS сказал:

Никогда ты ими не отловишь HardFault по невыровненному доступу, особенно на ядре, в котором его не может быть по определению.

А на каком ядре HF "не может быть по определению"?

[one_eight_seven 6]

Just now, VladislavS said:

Это другое. Безупречный с точки зрения стандарта языка код может легко в железе "чудеса" творить. Никогда ты ими не отловишь HardFault по невыровненному доступу, особенно на ядре, в котором его не может быть по определению.

Да, конечно. Однако, я спрашивал не чтобы сказать, что это использовать вместо разных компиляторов. Мне было интересно, есть ли что удобоваримое для C (не C++), и если есть, то как оно называется. Я пробовал несколько открытых, но там старый стандарт языка. Мне не подошло по большей части.

[repstosw 18]

7 minutes ago, one_eight_seven said:

Всегда довожу количество Warning'ов нуля, где это возможно

 

Прямо всех?  С -Wall и pedantic + Werror ?

[one_eight_seven 6]

3 minutes ago, __inline__ said:

Выходит, по-вашему,  ядро тоже бажное?  Я не отрицаю этого, так как баги программ накапливаются с ростом объёма кода, поэтому полностью избавиться от них крайне сложно.

Но есть тенденция, что у GCC больше шансов сделать код рабочим на -O3 или fast, чем у IAR.

В Linux есть и другое объяснение, я не собирал Gentoo, я больше по RedHat'ам, но там объяснение такое, что -O2 выбрано из-за того, что -O3, -Ofast используют агрессивный инлайнинг и это увеличивает cache footprint приложений, что резко негативно сказывается на производительности. И да, упоминается, что в редких случаях это может сломать ABI, но случаи эти явно описаны, и, если это ваш случай, то вы будете об этом знать: случайно такое сделать крайне маловероятно.