OSDev http://osdev.su/ |
|
Об эффективности трансляторов http://osdev.su/viewtopic.php?f=6&t=433 |
Страница 2 из 4 |
Автор: | Himik [ 31 июл 2011, 23:57 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
SII писал(а): Кроме того, похоже, GCC никто толком не тестирует ни на чём хоть малость нестандартном... Я один раз заглядывал в Bugzilla GCC, и создалось впечатление, что тестируют. Огромные листы незакрытых рапортов кочуют из версии в версию без шанса исправления - просто не хватает программистов. |
Автор: | SII [ 01 авг 2011, 00:49 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
Ну, я, например, попробовал собрать полный GCC 4.6 под MingW -- и обломился из-за тупейшей ошибки в одном из модулей адской библиотеки. Запостил баг, через некоторое время его исправили -- но оказалось, он не только в этой версии был, но и в двух или трёх последних 4.5. Отсюда ясно, что под МингВ в полном составе гецеце собирать не пытались, а ведь это, пожалуй, вторая по распространённости для него платформа (ну, может, третья). Понятно, что Аду мало кто использует, и по умолчанию она не собирается, но ведь разработчики самого пакета просто обязаны, если руководствоваться здравым смыслом, перед официальным выпуском очередной версии собрать её в полном комплекте для пятка основных платформ. А ещё раньше (во времена 4.4) натыкался на пару багов, тоже в адской библиотеке, которые выползли б не только под МингВ, но и под линухом тоже. Вот отсюда и впечатление, что полную сборку разработчики не делают даже под линухом, пока им багрепорт на голову не свалится... Himik писал(а): Огромные листы незакрытых рапортов кочуют из версии в версию без шанса исправления - просто не хватает программистов. Угу, но это больше говорит о порочности современного подхода к разработке крупных программных систем. Если по-хорошему, разработчики были бы просто обязаны прекратить развитие пакета до тех пор, пока уже найденные ошибки не будут устранены. Более того, если для "коммерсантов" игнорирование ошибок ещё можно понять (они ж бабло рубят на продажах), то для типа энтузазисьтов такое вообще непростительно. Но нет, предпочитают добавить 1001-ю неработоспособную в 90% случаев фичу, а не исправить уже хорошо известные ошибки... |
Автор: | Yoda [ 01 авг 2011, 17:34 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
Himik писал(а): Огромные листы незакрытых рапортов кочуют из версии в версию без шанса исправления — просто не хватает программистов. Я думаю, дело не только и даже не столько в отсутствии программистов. GCC (и ядро самого линуха) — проект настолько разросшийся, что у любого, даже талантливого программиста (если только он всю жизнь с этим не работал) при попытке разобраться не только в коде, но даже в структуре проекта, быстро вылезают из орбит глаза и начинается острый приступ мигрени. Бывает (в GNUсных проектах особенно), что проекты из-за вавилонского столпотворения разрастаются так, что выходят из под контроля. Примерно, как запутавшаяся леска. Экспериментируюя над идеологией ЯВУ, я пытался разобраться в сорцах GCC. Быстро зашёл в тупик и бросил это дело. Сейчас, работая над ядром ОС я мучительно начал изучать ядро Линукса. Как мне казалось, я проанализировал начальные процедуры инициализации. А затем впал в ступор, когда увидел, что их несколько и какая реально начинает работать — неясно. Очень может быть, что в разных условиях разные. Более того, я не смог определить следующий этап исполнения, обломался и расслабился. В конце концов, я пишу своё ядро, а не копирую линух. SII писал(а): по-хорошему, разработчики были бы просто обязаны прекратить развитие пакета до тех пор, пока уже найденные ошибки не будут устранены. Скорей не устранить ошибки, а хорошо структурировать и модулизировать проект, так, чтобы в нём было проще разобраться. Тогда и с ошибками будет намного проще. Ловить чертей в мутной воде на порядок сложней. Но для такого серьёзного шага нужен хороший менеджмент, с которым в ГНУсных проектах по-определению плохо, или переписывание проекта с нуля. Чаще идут как раз вторым путём. |
Автор: | SII [ 01 авг 2011, 18:31 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
Yoda писал(а): Чаще идут как раз вторым путём. И при этом повторяют те же самые ошибки... |
Автор: | SII [ 08 авг 2011, 21:24 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
Переписал свою ось с системы команд ARM на Thumb (оставив ARM там, где это необходимо: начало инициализации, первичные обработчики прерываний и подпрограммы управления прерываниями). При одинаковом функционале (собственно ядро, драйверы GPIO и UART плюс тестовая задача на Аде; на Thumb переведено только ядро без упомянутых модулей, а драйверы и задача оставлены на ARM) размер кода сократился с 13772 байтов до 10156. Соотношение размеров модулей ядра, которые целиком были переписаны с АРМы на Тумбу, можно увидеть по выдержкам из карт памяти, созданных компоновщиком: Код: 0x00000b04 0x0000016c Code RO 22 KERNEL common.o 0x00000dac 0x00000096 Code RO 29 KERNEL io.o 0x00000f44 0x00000070 Code RO 38 KERNEL memory.o 0x00000fb4 0x00000040 Code RO 41 KERNEL scheduler.o 0x00000ff4 0x00000114 Code RO 44 KERNEL signals.o 0x00001108 0x00000174 Code RO 47 KERNEL svc_handler.o 0x0000127c 0x000002b8 Code RO 50 KERNEL svc_io.o 0x00001534 0x00000020 Code RO 53 KERNEL svc_misc.o 0x00001554 0x000000dc Code RO 56 KERNEL svc_signals.o 0x00001630 0x000002a8 Code RO 59 KERNEL svc_sync.o 0x000018d8 0x000000dc Code RO 62 KERNEL svc_timer.o 0x000019b4 0x00000334 Code RO 65 KERNEL sync.o 0x00001ce8 0x000000bc Code RO 68 KERNEL tasks.o 0x00001da4 0x00000064 Code RO 71 KERNEL threads.o Код: 0x000012bc 0x0000025c Code RO 16 KERNEL common.o 0x00001638 0x000000c8 Code RO 29 KERNEL io.o 0x00001700 0x000000c4 Code RO 38 KERNEL memory.o 0x000017c4 0x00000060 Code RO 41 KERNEL scheduler.o 0x00001824 0x000001dc Code RO 44 KERNEL signals.o 0x00001a2c 0x000001b8 Code RO 56 KERNEL svc_handler.o 0x00001be4 0x00000404 Code RO 59 KERNEL svc_io.o 0x00001fe8 0x00000030 Code RO 62 KERNEL svc_misc.o 0x00002018 0x00000104 Code RO 65 KERNEL svc_signals.o 0x0000211c 0x00000330 Code RO 68 KERNEL svc_sync.o 0x0000244c 0x000000fc Code RO 71 KERNEL svc_timer.o 0x00002548 0x000004b0 Code RO 74 KERNEL sync.o 0x000029f8 0x00000134 Code RO 77 KERNEL tasks.o 0x00002b2c 0x00000060 Code RO 80 KERNEL threads.o Имеем 6020 байтов для ARM и 4294 для Thumb. При использовании Thumb-2 код становится ещё немного короче, поскольку можно использовать все регистры процессора, проще работать с константами и т.п. Например, в Thumb нельзя выполнить логическую операцию между регистром и константой, её надо сначала загрузить в другой регистр, ну а в Thumb-2 -- можно. Правда, при этом код команды займёт не 2 байта, а 4, но это всё равно выгодней хотя б потому, что придётся выполнить одну команду, а не две или даже три (в Thumb константа может быть загружена лишь в младший байт регистра, а в Thumb-2 с этим посвободнее: байтовую константу можно поместить, начиная с любого разряда регистра, плюс есть несколько особых возможностей загрузки, например, можно сразу загрузить 0000FFFF, хотя сама по себе константа в коде команды занимает байт). |
Автор: | Himik [ 14 авг 2011, 09:34 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
Справедливости ради надо отметить, что параметры оптимизации gcc -O1 -O2 -O3 оптимизируют по скорости за счёт увеличения размера, поэтому сравнивать по байтам результаты нельзя. И из моего опыта, адекватно оптимизирует только режим -O1, а остальные бесполезно увеличивают размер кода. |
Автор: | SII [ 14 авг 2011, 13:02 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
1. Транслятор Кейла использовался в точно таком же режиме -- оптимизация по скорости в ущерб размеру. 2. Даже при включенной оптимизации по размеру GCC вчистую проигрывает Кейлу, оптимизирующему по скорости. 3. Ну а Ваш опыт, если он верен и распространяется на разные платформы, а не только ИА-32 (на ней же проверяли, надо полагать), лишний раз говорит о том, что GCC -- плохой транслятор, состряпанный как попало и использующийся больше по "политическим" и историческим причинам, чем по техническим. |
Автор: | Himik [ 15 авг 2011, 19:01 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
SII писал(а): 1. Транслятор Кейла использовался в точно таком же режиме -- оптимизация по скорости в ущерб размеру. 2. Даже при включенной оптимизации по размеру GCC вчистую проигрывает Кейлу, оптимизирующему по скорости. Это круто. SII писал(а): 3. Ну а Ваш опыт, если он верен и распространяется на разные платформы, а не только ИА-32 (на ней же проверяли, надо полагать), лишний раз говорит о том, что GCC -- плохой транслятор, состряпанный как попало и использующийся больше по "политическим" и историческим причинам, чем по техническим. Для IA-32 с параметром -O1 генерируется вполне достойный код, поэтому для меня он не плохой. Может быть, лет через 10 кодогенератор и под ARM допилят. Думаю, что это дело времени. |
Автор: | SII [ 15 авг 2011, 21:04 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
Попросил Грина собрать его проектик (несколько больше 30 тыщ строк на Си++) в Визуал Студии (2010) и GCC 4.4.0 по Винду. Опенсорц разбит вдребезги на любых режимах. Ниже -- размер секций, содержащих код: - MSVC, оптимизация по размеру -- 535566; - MSVC, оптимизация по скорости -- 612878; - GCC, -Os -- 858668; - GCC, -O1 -- 979764; - GCC, -O2 -- 990384. Таким образом, и на ИА-32 ГЦЦ, оптимизирующий по размеру, вчистую проигрывает по этому самому размеру коммерческому транслятору, оптимизирующему что по скорости, что по размеру. Лично меня результат не удивляет. Оптимизация в основной своей массе является машиннонезависимой, и, если транслятор генерирует плохой код для АРМ, он будет генерировать плохой код для любой другой платформы. Машиннозависимая оптимизация позволяет (в теории) лишь несколько грамотнее распределить регистры с учётом их специальных функций да подобрать команды и их последовательности пооптимальнее, но не способна оптимизировать, например, циклы. В общем, лишний раз убедился: ГЦЦ -- плохой транслятор. Скорей, даже очень плохой... И допилить его не допилят никогда: для этого нужна жёсткая дисциплина избранных специалистов, а не свободное творчество всех желающих... |
Автор: | Himik [ 15 авг 2011, 23:17 ] |
Заголовок сообщения: | Re: Об эффективности трансляторов |
SII, для меня размер не важен, и не является показателем. А в режиме компиляции по скорости размер не является показателем как таковым, а ты его приводишь как доказательство незнай чего. |
Страница 2 из 4 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |