[Tannen 0]

Вопрос конечно некорректный ! но все же поделитесь своим опытом , кто работает на ARM .

Я работаю с Infineon XC2000 c линкером входящим в систему VX-ToolSet от Tasking - и при линковке больших проектов с объемом памяти более 500 K и количеством переменных более 2 тыс - линкер работает очень медленно до 5 минут ! :07: Вопрос кто сталкивался с подобными проблемами на ARM ( как близкие по возможным объемам памяти МК) на больших проектах ?

[AlexandrY 3]

А я бы сказал, что это ключевой вопрос.

Просто он обнаруживается слишком поздно, когда слезть с компилятора уже нельзя или ему нет альтернатив к в случае с линуксом или WinCE.

 

В свое время тестировал большинство имевшихся компилеров для ARM.

 

Рекордсменом по тормозам оказался компилер от TI для OMAP-ов входящий в комплект Code Composer Studio.

Дальше самым медленным был конечно GCC в различных вариантах.

 

Самым быстрым был CodeWarrior от Freescale.

Вторым по быстроте был RealView от ARM Ltd, он же Keil RVDK

Остальные типа IAR, CrossWorks, Multi2000, MicroCross и т.д. были посередине.

 

Разница во времени компиляции с линковкой могла составлять десятки раз.

 

C таскингом отдельная песня. Я его даже не тестировал для ARM-ов. Под XC166 он линкует так долго, что вообще пропадает желание иметь с ним дело.

Например, пакет для несложного GSM/GPRS модема (примитивная RTOS, без явы, все сервисы по минимуму, бинарный образ около 1 мега) может линковать по 10-15 мин.

 

К слову, RealView компилирует с нуля весь проект из 1400 файлов за 5 мин. 20 сек. из них линковка в конце непосредственно длится 10 сек. Получается 700 Кб бинарник.

 

 

 

 

 

 

Вопрос конечно некорректный ! но все же поделитесь своим опытом , кто работает на ARM .

Я работаю с Infineon XC2000 c линкером входящим в систему VX-ToolSet от Tasking - и при линковке больших проектов с объемом памяти более 500 K и количеством переменных более 2 тыс - линкер работает очень медленно до 5 минут ! :07: Вопрос кто сталкивался с подобными проблемами на ARM ( как близкие по возможным объемам памяти МК) на больших проектах ?

[Tannen 0]

Спасибо AlexandrY !

Добавлю от себя что - в проекте о котором идет речь - до 500 файйлов и самое смешное - что сборка ( то есть компиляция и линковка выполняется не из среды Eclipso (чур меня - торомоза вообще дикие даже на маленьких проектах. т.к. java ) а с помощью пакетного командного файла - ну так быстрее ... все ничего только линкер :07: такой думающий - не смотря на мощную рабочую станцию дает загрузку процесора на все 100 %

А я бы сказал, что это ключевой вопрос.

Просто он обнаруживается слишком поздно, когда слезть с компилятора уже нельзя или ему нет альтернатив к в случае с линуксом или WinCE.

 

В свое время тестировал большинство имевшихся компилеров для ARM.

 

Рекордсменом по тормозам оказался компилер от TI для OMAP-ов входящий в комплект Code Composer Studio.

Дальше самым медленным был конечно GCC в различных вариантах.

 

Самым быстрым был CodeWarrior от Freescale.

Вторым по быстроте был RealView от ARM Ltd, он же Keil RVDK

Остальные типа IAR, CrossWorks, Multi2000, MicroCross и т.д. были посередине.

 

Разница во времени компиляции с линковкой могла составлять десятки раз.

 

C таскингом отдельная песня. Я его даже не тестировал для ARM-ов. Под XC166 он линкует так долго, что вообще пропадает желание иметь с ним дело.

Например, пакет для несложного GSM/GPRS модема (примитивная RTOS, без явы, все сервисы по минимуму, бинарный образ около 1 мега) может линковать по 10-15 мин.

 

К слову, RealView компилирует с нуля весь проект из 1400 файлов за 5 мин. 20 сек. из них линковка в конце непосредственно длится 10 сек. Получается 700 Кб бинарник.

[sanek_spb 0]

Так, для справки, проект на арме, линкер RVCT линкует образ размером ~50 метров около 5 минут, из 50 метров половина константные данные, было время когда какая-то сборка тоже сьюта линковала тот же проект больше 30 минут. Самописный линкер под вин32 объектники от микрософтовского компилера в объем пол метра линковал секунду.

[HARMHARM 0]

Может я открою Америку, но можно использовать параллельную компиляцию. У меня сэкономилось порядка 30% времени при использовании четырех нитей. Собираю через make -j4.

[klen 1]

Дальше самым медленным был конечно GCC в различных вариантах.

.

.

.

Остальные типа ..... CrossWorks .....были посередине.

 

Под GCC Вы имели ввиду LD который входит в состав binutils . от очевидно не сам линкер виноват, CrossWorks - использует тотже LD.

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

 

опция -j хороша для компиляции независимых файлов, в терминах маке это разные независимые цели. а вот линковка ОДНОГО бинаряя из кучи объектников маке не распаралелит.

[sergeeff 1]

Пару лет тому читал одну заметку, где один программист советовал пользоваться давно известным решением - RAM-диском. У него очень большие проекты стали собираться в разы быстрее. Тем более сейчас DRAM дешевы, как никогда.

[klen 1]

я так и делаю

[zltigo 2]

я так и делаю

Много лет уже так не делаю, ибо многооборотные диски высокой емкости имеющие мегабайты кэша на борту и, естественно, висящие на эффективно использумом UDMA под операционками имеющими нормальное кэширование, давно уже не являются заметным ограничивающим фактором.

[AlexandrY 3]

Кстати, очень верно.

 

Перфоманс монитор IDLE состояний диска в винде во время компиляции в RVCT показывает цифры близкие к 100%

Т.е. диск вообще почти не используется.

 

 

Много лет уже так не делаю, ибо многооборотные диски высокой емкости имеющие мегабайты кэша на борту и, естественно, висящие на эффективно использумом UDMA под операционками имеющими нормальное кэширование, давно уже не являются заметным ограничивающим фактором.

[klen 1]

у меня особый случай.

работаю на ноуте с ноутным винчестером(5400rpm). собираю и отлаживаю большой не ембедерский проект. выделил из озу 1Гб рамдиска на нем и с него собирается и грузится при старте. получил ускорение в 4 раза. с 15минут до 3-4минут сборка, загрузка в тойже пропорции.

 

вообще не вижу причин не использовать ОЗУ если его моного , к пример все tmp у меня тоже в этот 1Гб адресованы. Вичестер целее будет, тепла меньше выделится, PCI-E меньше загрузка.

[AlexandrY 3]

Чет не понял вашей технологии.

 

Вы что же перед компиляцией копируете все файлы проекта на RAM диск, а потом их там и редактируете или качаете обратно?

 

Или объектные файлы только на RAM диск пишете, а потом их обратно перекачиваете?

 

Так одно такое копирование десятка тысяч файлов мало не покажеться.

А делать такую операцию постоянно вообще кошмар.

 

 

 

 

у меня особый случай.

работаю на ноуте с ноутным винчестером(5400rpm). собираю и отлаживаю большой не ембедерский проект. выделил из озу 1Гб рамдиска на нем и с него собирается и грузится при старте. получил ускорение в 4 раза. с 15минут до 3-4минут сборка, загрузка в тойже пропорции.

 

вообще не вижу причин не использовать ОЗУ если его моного , к пример все tmp у меня тоже в этот 1Гб адресованы. Вичестер целее будет, тепла меньше выделится, PCI-E меньше загрузка.

[dch 0]

на четверке до шести часов компилилось :-)

[vetal 0]

Чет не понял вашей технологии.

 

Вы что же перед компиляцией копируете все файлы проекта на RAM диск, а потом их там и редактируете или качаете обратно?

 

Или объектные файлы только на RAM диск пишете, а потом их обратно перекачиваете?

Обычный рам диск. Я примерно такой подход на работе использую, правда чуть поменьше выделил.

Cоздается обычный рам диск, назначается файл образа и работаем. При загрузке и выкрузке операционной системы этот диск загружается из образа или сохраняется в него.

Без бесперебойника я бы не рекомендовал так делать(в буке он встроенный :) )

[AlexandrY 3]

А, понял, интересная практика для экстремалов.

Питание еще так скажу бледнеет перед тем как валят систему разные USB примочки начиная с флешей и кончая осцилами.

RAM диск самое то чтобы почувствовать суровую правду жизни.

 

Обычный рам диск. Я примерно такой подход на работе использую, правда чуть поменьше выделил.

Cоздается обычный рам диск, назначается файл образа и работаем. При загрузке и выкрузке операционной системы этот диск загружается из образа или сохраняется в него.

Без бесперебойника я бы не рекомендовал так делать(в буке он встроенный :) )