компиляторы -
IAR V5.40.2.51604/W32
RVCT4.0 [Build 650]
(Sourcery G++ Lite 2009q1-161) 4.3.3

Задача:
распаковка LZMA из внутренней Flash, только распаковка, данные никуда не отсылаются.
запакованный размер - 244625
распакованный - 605992
размер словаря 8 кб
данные - прошивка от блекфина.
оптимизация максимальная по скорости

Платформа:
ARM - LPC2138
частота 50 Mhz MAM включен

размер кода (только декодер)


Время выполнения в ms (измерял с помощью таймера с прескалером 0)
код выполнялся из памяти


код из флеша


В тумбе IAR генерит более быстрый и компактный код по сравнению с RVCT.
В ARM из flash разница в скорости ~0.2% что несущественно, а вот код ~8% компактнее.

С GNUC - интересно в тумбе код большой, но более быстрый. Посмотрел по листингу - это связано с тем что GNUC в тумбе использует r8, r9 ( r10,r11 не использовал)

PS - общий проект в IAR, разными компиляторами компилировал только функцию декодера, а т.к. все EABI, то IARовсикй линкер без проблем жрал. Поэтому измерение времени для разных компилеров корректно - именно время распаковки.

Сообщение отредактировал KRS - Oct 27 2009, 16:15

Вот ещё тестирование.
http://www.phyton.ru/pages/page44.html

Голые цифры - это не интересно. Код в студию, тонкие моменты из листингов - тоже.

Хотя лично мне с гнусем все ясно - теперь это компилятор для x86, а жаль, задумка была отличная.

LZMA брал отсюда
http://www.7-zip.org/sdk.html версия 4.65
отлично компилится и под win и под arm
для распаковки нужны только 3 файла LzmaDecode.* и Types.h

реально используется функция LzmaDecodeReal ( потому что случай вырожденный есть все запакованные данные и распаковка сразу целиком по словарю блоками по 8 кб)
размеры приведены как раз именно функции LzmaDecodeReal


GNUC в некоторых моментах умеет делать то что другие не умеют, например вот старшие регистры в тумбе задействовать и не только для пересылки ( еще сложение там работает). Но глобально оптимизирует хуже.


Если кому интересно, могу потом (надо доработать немного) выложить код обретки LzmaDecodeReal для вырожденного случая, когда все данные для распаковки доступны в адресном пространсве, а распаковка идет либо сразу целиком, либо кусками по размеру словаря.
размер кода виден выше, скорость тоже. Пакует лучше deflate на 30% примерно.

Обоснуйте, с каких это пор ?

С тех пор, как его бездумно начали точить под архитектуру x86, не учитывая наличие других. Наглядный пример - векторизация.

Улучшение x86 не значит ухудшение embedded one. векторизацию точили для SMP Cell/PPC/x86_64, не думаю что она вообще имеет какой-либо смысл для avr и прочих embedded targets. В любом случае отключить ее если что можно всегда (-fno-tree-vectorize).
Начиная с версий 4.x.x, gcc показывает стабильный рост качества генерируемого кода, при этом оставаясь бесплатным , многоплатформенным, имея нехилый саппорт и базу юзеров. Как по мне - это лучший из компиляторов именно по этим причинам, невзирая на проценты, которые он может быть, местами, где-то, кому-то и проигрывает.

P.S. А узкие места все и так на асме пишут если припечет

Ошибаетесь. Для PowerPC векторизация не нужна. x86 only.



На самом деле вопрос куда глубже, чем втыкание ключа. Вопрос заключается в том, что данная оптимизация была прикручена без обратной связи, т.е. производится независимо от того, лучше становится код, или хуже. Лучше он может становиться только для ядер с отсутствием пост/пред/инкрементной/декрементной адресации, т.е. x86. И таких "оптимизаций" там уже масса.

Вот это и есть "бездумное затачивание".

Векторизация использует SIMD инструкции, для PPC, в частности, используется набор Altivec, для x86 - SSE/3DNOW, вот пример векторизации для PPC:

gcc -O2 -ftree-vectorize -maltivec -ftree-vectorizer-verbose=5 ....



Обратная связь - это из другой оперы и к статическим методам оптимизации отношения не имеет. Называется такая оптимизация profile-directed optimization и управляется -fprofile-arcs / -fbranch-probabilities / -fprofile-use и т.д.



Откуда такая инфа ?

Да нет. Я не об этом. Я о той векторизации, которая заменяет

на


Т.к. x86 имеет адресацию типа [ra+rb], но не имеет адресацию типа [ra++], результат должен быть ясен.



Опера как раз та. Векторизация выполняется на этапе генерации RTL, а обратная связь нужна от кодегенератора. Тогда бы генератору RTL надавали по рукам за счет штрафов за выходной код. А этого нет.

Это не совсем векторизация - это банальная оптимизация циклов, просто имеет она несколько уровней. Сначала выкидываются лишние переменные и присваивания, перестраивается и упрощается тело цикла, счетчик по мере возможности строиться в сторону уменьшения, и т.д. А один из последних уровеней - instruction scheduling использует именно те инструкции, которые эффективны на конкретной платформе.
Также не нужно путать cost estimation для векторизации и оптимизацию с использованием обратной связи. Первая имеет смысл только для CPU с SIMD инструкциями, толку от нее на embedded, вот почему ее и реализовали только для PPC/Cell/x86. Вторая - конает всегда, правда меня всегда интересовал момент как получить эти profile данные на embedded платформе ?
Вопросы оптимизация циклов - это из третьей оперы, потому как там еще нужно учитывать конвейер, для платформ где он есть.

На моих проектах (RTOS,TCP/IP etc) для ARM7/9 самый быстрый компилятор - RVCT,
затем - IAR, затем - GCC, но разница в скорости - в предела 5-10%.

А вот для Cortex-M3 IAR 5.40 генерит очень медленный код (даже на максимальной оптимизации).

Размер кода у RVCT и IAR примерно одинаков, а у GCC - намного больше(иногда на 40% и это не
библиотеки).

Это так должно быть. На самом деле в гнусе не так. Из-за прикрученной векторизации переменная заменяется на индекс и работа с указателями заменяется на array[index]. И это производится на этапе генерации RTL (т.е. гуано закладывается еще на машинно-независимом уровне). Но в правильном компиляторе за это должен дать по рукам генератор кода для таргета из RTL. А в гнусе этого нет.



Я ничего не путаю. Бывают разные обратные связи - Вы про обратную связь через профайлер, я про обратную связь от следующих этапов генерации кода к предыдущим.

У кортекса получилась довольно сложная, с точки зрения компилирования архитектура - особенно если выполнять из медленной FLASH, потому что надо держать баланс между использованием только 16 битных команд и производительностью, особенно на STM32 - у которых медленная флеша. На IAR уже давно были нарекания на кортекс - он многие вещи не умел использовать, я уже тут как то выкладывал листинги работы с битовыми полями - код IAR вообще никуда не годился! Но теперь они постоянно пишут что код для кортекса стали намного лучше генерить, видно это не так

Если разница в скорости 10%, а код больше на 40%, то это библиотеки или вы не отключили функции дебагера.
GCC позволяет компилировать программы под Linux и uCLinux. Плюс он бесплатен.
А быстродействие зависит от исходного текста программы: для сжатия по JPEG получите одно, для TCP/IP- другое.
Поэтому выбираешь компилятор из личных предпочтений, а не по бенчмаркам (так как все они одного класса).