OSDev

для всех
Текущее время: 27 апр 2024, 17:25

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 36 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Re: Об эффективности трансляторов
СообщениеДобавлено: 31 июл 2011, 23:57 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1088
Откуда: Балаково
SII писал(а):
Кроме того, похоже, GCC никто толком не тестирует ни на чём хоть малость нестандартном...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об эффективности трансляторов
СообщениеДобавлено: 01 авг 2011, 00:49 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1418
Ну, я, например, попробовал собрать полный GCC 4.6 под MingW -- и обломился из-за тупейшей ошибки в одном из модулей адской библиотеки. Запостил баг, через некоторое время его исправили -- но оказалось, он не только в этой версии был, но и в двух или трёх последних 4.5. Отсюда ясно, что под МингВ в полном составе гецеце собирать не пытались, а ведь это, пожалуй, вторая по распространённости для него платформа (ну, может, третья). Понятно, что Аду мало кто использует, и по умолчанию она не собирается, но ведь разработчики самого пакета просто обязаны, если руководствоваться здравым смыслом, перед официальным выпуском очередной версии собрать её в полном комплекте для пятка основных платформ. А ещё раньше (во времена 4.4) натыкался на пару багов, тоже в адской библиотеке, которые выползли б не только под МингВ, но и под линухом тоже. Вот отсюда и впечатление, что полную сборку разработчики не делают даже под линухом, пока им багрепорт на голову не свалится...

Himik писал(а):
Огромные листы незакрытых рапортов кочуют из версии в версию без шанса исправления - просто не хватает программистов.


Угу, но это больше говорит о порочности современного подхода к разработке крупных программных систем. Если по-хорошему, разработчики были бы просто обязаны прекратить развитие пакета до тех пор, пока уже найденные ошибки не будут устранены. Более того, если для "коммерсантов" игнорирование ошибок ещё можно понять (они ж бабло рубят на продажах), то для типа энтузазисьтов такое вообще непростительно. Но нет, предпочитают добавить 1001-ю неработоспособную в 90% случаев фичу, а не исправить уже хорошо известные ошибки...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об эффективности трансляторов
СообщениеДобавлено: 01 авг 2011, 17:34 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 970
Откуда: Дагоба
Himik писал(а):
Огромные листы незакрытых рапортов кочуют из версии в версию без шанса исправления — просто не хватает программистов.

Я думаю, дело не только и даже не столько в отсутствии программистов. GCC (и ядро самого линуха) — проект настолько разросшийся, что у любого, даже талантливого программиста (если только он всю жизнь с этим не работал) при попытке разобраться не только в коде, но даже в структуре проекта, быстро вылезают из орбит глаза и начинается острый приступ мигрени. Бывает (в GNUсных проектах особенно), что проекты из-за вавилонского столпотворения разрастаются так, что выходят из под контроля. Примерно, как запутавшаяся леска. Экспериментируюя над идеологией ЯВУ, я пытался разобраться в сорцах GCC. Быстро зашёл в тупик и бросил это дело. Сейчас, работая над ядром ОС я мучительно начал изучать ядро Линукса. Как мне казалось, я проанализировал начальные процедуры инициализации. А затем впал в ступор, когда увидел, что их несколько и какая реально начинает работать — неясно. Очень может быть, что в разных условиях разные. Более того, я не смог определить следующий этап исполнения, обломался и расслабился. В конце концов, я пишу своё ядро, а не копирую линух.

SII писал(а):
по-хорошему, разработчики были бы просто обязаны прекратить развитие пакета до тех пор, пока уже найденные ошибки не будут устранены.

Скорей не устранить ошибки, а хорошо структурировать и модулизировать проект, так, чтобы в нём было проще разобраться. Тогда и с ошибками будет намного проще. Ловить чертей в мутной воде на порядок сложней. Но для такого серьёзного шага нужен хороший менеджмент, с которым в ГНУсных проектах по-определению плохо, или переписывание проекта с нуля. Чаще идут как раз вторым путём.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об эффективности трансляторов
СообщениеДобавлено: 01 авг 2011, 18:31 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1418
Yoda писал(а):
Чаще идут как раз вторым путём.


И при этом повторяют те же самые ошибки...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об эффективности трансляторов
СообщениеДобавлено: 08 авг 2011, 21:24 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1418
Переписал свою ось с системы команд 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, хотя сама по себе константа в коде команды занимает байт).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об эффективности трансляторов
СообщениеДобавлено: 14 авг 2011, 09:34 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1088
Откуда: Балаково
Справедливости ради надо отметить, что параметры оптимизации gcc -O1 -O2 -O3 оптимизируют по скорости за счёт увеличения размера, поэтому сравнивать по байтам результаты нельзя. И из моего опыта, адекватно оптимизирует только режим -O1, а остальные бесполезно увеличивают размер кода.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об эффективности трансляторов
СообщениеДобавлено: 14 авг 2011, 13:02 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1418
1. Транслятор Кейла использовался в точно таком же режиме -- оптимизация по скорости в ущерб размеру.
2. Даже при включенной оптимизации по размеру GCC вчистую проигрывает Кейлу, оптимизирующему по скорости.
3. Ну а Ваш опыт, если он верен и распространяется на разные платформы, а не только ИА-32 (на ней же проверяли, надо полагать), лишний раз говорит о том, что GCC -- плохой транслятор, состряпанный как попало и использующийся больше по "политическим" и историческим причинам, чем по техническим.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об эффективности трансляторов
СообщениеДобавлено: 15 авг 2011, 19:01 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1088
Откуда: Балаково
SII писал(а):
1. Транслятор Кейла использовался в точно таком же режиме -- оптимизация по скорости в ущерб размеру.
2. Даже при включенной оптимизации по размеру GCC вчистую проигрывает Кейлу, оптимизирующему по скорости.

Это круто.
SII писал(а):
3. Ну а Ваш опыт, если он верен и распространяется на разные платформы, а не только ИА-32 (на ней же проверяли, надо полагать), лишний раз говорит о том, что GCC -- плохой транслятор, состряпанный как попало и использующийся больше по "политическим" и историческим причинам, чем по техническим.

Для IA-32 с параметром -O1 генерируется вполне достойный код, поэтому для меня он не плохой.
Может быть, лет через 10 кодогенератор и под ARM допилят. Думаю, что это дело времени.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об эффективности трансляторов
СообщениеДобавлено: 15 авг 2011, 21:04 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1418
Попросил Грина собрать его проектик (несколько больше 30 тыщ строк на Си++) в Визуал Студии (2010) и GCC 4.4.0 по Винду. Опенсорц разбит вдребезги на любых режимах. Ниже -- размер секций, содержащих код:

- MSVC, оптимизация по размеру -- 535566;
- MSVC, оптимизация по скорости -- 612878;
- GCC, -Os -- 858668;
- GCC, -O1 -- 979764;
- GCC, -O2 -- 990384.

Таким образом, и на ИА-32 ГЦЦ, оптимизирующий по размеру, вчистую проигрывает по этому самому размеру коммерческому транслятору, оптимизирующему что по скорости, что по размеру. Лично меня результат не удивляет. Оптимизация в основной своей массе является машиннонезависимой, и, если транслятор генерирует плохой код для АРМ, он будет генерировать плохой код для любой другой платформы. Машиннозависимая оптимизация позволяет (в теории) лишь несколько грамотнее распределить регистры с учётом их специальных функций да подобрать команды и их последовательности пооптимальнее, но не способна оптимизировать, например, циклы.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об эффективности трансляторов
СообщениеДобавлено: 15 авг 2011, 23:17 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1088
Откуда: Балаково
SII, для меня размер не важен, и не является показателем. А в режиме компиляции по скорости размер не является показателем как таковым, а ты его приводишь как доказательство незнай чего.


Последний раз редактировалось Himik 15 авг 2011, 23:48, всего редактировалось 4 раз(а).

Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 36 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 13


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB