новый компилятор в OpenBSD

Original author: Mark Espie
  • Translation
По мотивам сообщения osnews.com/story.php/18771/More-on-OpenBSDs-New-Compiler

Несколько недель назад проект OpenBSD объявил о том, что Portable C Compiler был добавлен в дерево исходников OpenBSD. И разработчики будут стараться сделать его полноценной заменой GCC. Почему?

По словам Марка Эспи (Mark Espie) undeadly.org/cgi?action=article&sid=20070915195203&pid=52 причина в том, что разработчики GCC приследуют иные цели, чем разработчики OpenBSD. Разницу он показывает следующими пунктами.

(1) GCC сейчас — это почти коммерческая разработка. Ей занимаются дистрибьюторы коммерческих дистрибутивов Linux и Apple. Компилятор нацелен на быстрые i386 и PowerPC процессоры только. При этом, его затачивают под набор высоких баллов в SPEC. (От меня) Как известно, заточка компиляторв под определённые программы осуществляется дедовским способом — просто увеличивается база шаблонов, которые компилятор должен узнавать и выдавать для них заранее написанный человеком код. Поэтому... (От Марка) Но компилятор становится всё больше и больше, всё медленней и медленней, при этом намного. (От меня) В чём с сожалением убеждается любой пользователь Gentoo в последние несколько лет.

(2) Предупреждения в GCC бесполезные. Компиляция с -Wall сообщает о множестве верных вещей, и о небольшом количестве неверных.

(3) Весь дизайн GCC извращён настолько, что никто не может даже выделить front-end и back-end компилятора (от меня: истинная правда, помниться, как мы занимались с gcc любовью в попытках научить понимать его нерегистровые архитектуры). Он корявый, начиная с дизайна (broken by design), так как GPL'ный народ боится, что коммерческие организации смогут украсть backend или frontend и прицепить их к закрытым языкам или кодогенераторам (от меня: странный вывод, однако). Возможно, это правда. Но это не позволяет создавать интересные инструменты, такие как анализаторы промежуточного кода. И это так же не позволяет использовать backend'ы для старых архитектур c новыми компиляторами.

(4) В результате, нельзя поиметь новые интересные фишки новой версии GCC, не потеряв старые интересные фишки (от меня: угу, чтобы скомпилировать QEMU до сих пор приходиться таскать с собой GCC 3.)… Каждое обновление GCC — это инженерный кошмар, потому что здесь нет простого выбора: получаете возможности, но теряете важные особенности. (От меня) Ну, на самом деле, это проявляется редко, но если проявляется, то действительно геморрой.

(5) Так же очень сложно заниматься разработкой GCC. Их система ветвления делает весьма вероятным то, что важная работа пропадёт между разломами (cracks) (и это случается постоянно). Если вы разрабатываете код для GCC, это нужно делать на самой свежей ветке, что довольно сложно, если ваша платформа в настоящее время неработоспособна (случается постоянно если вы не под linux/i386) (от меня: вероятно, имеется в виду то, что gcc-i686-pc-bsd новой версии не работает). Даже тогда, когда вы приспосабливаетесь, тяжело писать код в согласии со стандартами кодирования GNU, которые, возможно, самые трудные для чтения для Си. Очевидно, что они были придуманы lisp-программистом. В результате я (Марк) даже потерял интерес к переписыванию и отправке в репозиторий GCC нескольких кусков кода.

(6) Некоторые последние усовершенствования не имеют шансов работать в OpenBSD, например, преразобранные include'ы, которые опираются на mmap() по фиксированному адресу (от меня: странное решение разработчиков GCC. Намного ли сложнее было воспользоваться тем адресом, который возвращает mmap()?)

(7) Существует несколько мест в GCC и G++, где вы не можете получить полную функциональность, не имея аналога glibc (от меня: а параноидальные OpenBSD'шники, естественно, полного такого аналога не имеют, потому что в нём много багов).

(8) Некоторые методы оптимизации определённо опасны, и неправильны для нас (например, выбрасывание во время оптимизации заполнений памяти, даже если они имеют дело с криптоключами) (от меня: ну да, плохо будет, когда ваш memset(0, 256, &rsakey) компилятор выкинет из кода, потому что больше обращений к rsakey не будет. Плохо, потому, что ту же физическую старницу памяти может получить другой процесс)

(9) И не забывайте кошмар, связанный с autoconf/libtool/automake (от меня: о да, детка). Чёрт, даже у самих GCC'шников обновление инфраструктуры для совместимости с последними automake'ами заняло несколько лет. И при этом, GCC — единственная програма из дерева переносимых (ports tree) которая на самом деле использует внутреннюю реализацию libtool. Её конфигурация и реконфигурация полностью заваливается, когда вы пытаетесь использовать libtool системы.

Я (Марк) на самом деле мог бы продолжать ещё на нескольких страницах. Я был мэйнтейнером GCC на OpenBSD в течении нескольких лет и буду счастлив преключиться на другой компилятор, настолько разочаровывающей был путь с GCC.

(От меня) Вот такой вот он, GCC. У меня был некоторый опыт общения с GCC на уровне исходников, это действительно тихий ужас. Хотя, в последних версиях код становиться всё более структурированным, но каши по-прежнему очень много. И вряд ли станет меньше, потому что постоянно идёт подгонка под конкретные программы. GCC можно сравнить с другими компиляторами и увидеть, насколько он действительно сложен, и насколько перегружен анализом шаблонов, а не интеллектуальной оптимизацией. Взять хотябы тот же TCC, или PCC. А ещё лучше посмотреть на реактивные компиляторы в Plan9.

Так что, Linux'у ещё есть куда развиваться и стремиться.

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 45

    0
    перевод: mikhanoid

    Да, действительно, механоид...
      +2
      А что поделаешь? : ) Никто другой же не перевёл. А о проблеме с оптимизацией memset'ов знать нужно многим.
        +2
        Статья хорошая, но проверьте правописание -ться и -тся в Ваших заметках, а то прям спотыкаюсь при чтении.
      0
      комментарии от себя может быть как-нибудь выделить? например, курсивом.
      По субжу:
      Portable C Compiler это же по-моему нечто очень древнее. Они хотят его возрадить и развить до уровня теперешнего GCC? GNU Compiler Collection можно ругать, но работа по созданную нечто подобного потребует огромного колличества человека времени и инвестиций. Ведь как правильно замечено gcc сейчас развивается отнюдь не энтузиастами.
        +1
        Он начался давно, но его поддерживают. Я посмотрел исходники, там есть тексты, датированные 2003 годом.

        Конечно, для разработки нового GCC понадобиться столько же усилий, но нужно ли разрабатывать нечто подобное GCC? Лично я не сомневаюсь, что есть способы организовать набор компиляторов намного более простым способом, соответсвенно, и разработать его можно быстрее. Тем более, если не требовать полной совместимости с GCC, в котором немало особенностей. Пример этому - компиляторы в Plan9.
          +1
          А тем временем OpenBSD уходит всё дальше и дальше в сторону HURD'а (то есть очень-крутой-в-чём-то-одном-системы, которая во всём остальном настолько кошмарна, что её тольком никто не пользовал и пользовать не будет). Отсюда и все проблемы с GCC. Он отлично работает на тех платформах, на которых люди его реально разрабатывают и используюут (Linux, MacOS, etc) - но вряд ли можно сильно обижаться на то что разработчики игнорируют желания и чаянья тех нескольких человек, которые разрабатывают GCC под OpenBSD (такие вообще существовали когда-нибудь? по моему максимум что пользователи OpenBSD делали - правили ошибки совместимости GCC и OpenBSD).

          Что касается сложности компилятора, то GCC кажется вам сложным только потому что вы никогда не видели исходников ICC или SunPro...

          GCC 4.2 - уже гораздо более разумный, быстрый и совместимый компилятор, чем ветка 3.x (даже ATLAS говорит что больше не нужно заморачиваться с разными версиями ICC, GCC 3.x и прочим - используйте GCC 4.2 и будет вам "щастя горстями"). QEMU, скажем, отлично собирается GCC 4.2 (если взять версию из CVS).

          Что касается не вполне удачного выбора RTL в качестве промежуточного языка для общения между front-end'ом и back-end'ем сделанную 20 лет назад - ну это в 4.x тоже ведь начали изживать. Ибо таки проблема и не только для портирования на нерегистровые архитектуры... Но сказать что этот подход изначально порочен - нельзя ибо некоторые оптимизации нельзя сделать на ином уровне, а вводить промежуточный язык только ради того чтобы развести front-end и back-end - бред (TreeSSA появился вовсе не для этой цели).

          В общем если вас не интересует скорость работы вашего кода - то вы можете использовать PCC, TCC и прочее. Так как разработчики OpenBSD уже давно решили что "оно им не надо", то выбор выглядит разумным: какой смысл возиться со сложными и неоднозначными инструментами если предоставляемые ими преимущества тебя просто не волнуют ?
        0
        В FreeBSD как-то хотели open watcom импортировать.
          –1
          Не открою Америку через форточку если скажу, что GCC это самый плохой ныне существующий компилятор, конечно, кроме всех остальных:)
            0
            Вижу, что хабралюди имеют хорошую привычку читать только по пол-предложения. Ну-ну, в том же духе:)
              +1
              Просто очень криво мысль сформулировал.
                +1
                Да не - просто люди в Интернете не имеют привычки вдумчиво читать что-либо. А журналисты всполошились: дескать не хотим для роботов писать! Только вот в случае постоянного цейтнота люди воспринимают "заумные" фразы ничуть не лучше роботов, что и показал проведённый ytsuken'ым эксперимент...
          • UFO just landed and posted this here
              0
              Давно сравнивали ? Разработчики ATLAS'а, в общем-то, фанаты скорости и они пишут следующее: "For ATLAS 3.8.0, all architectural defaults are set using gcc 4.2 only (the one exception is MIPS/IRIX, where SGI’s compiler is used). In most cases, switching these compilers will get you worse performance and accuracy, even when you are absolutely sure it is a better compiler and flag combination! In particular we tried the Intel compiler icc (called icl on Windows) on Intel x86 platforms, and overall performance was lower than gcc. Even worse, from the documentation icc does not seem to have any firm IEEE floating point compliance unless you want to run so slow that you could compute it by hand faster. This means that whenever icc achieves reasonable performance, I have no idea if the error will be bounded or not. I could not obtain access to icc on the Itaniums, where icc has historically been much faster than gcc, but I note that the performance of gcc4.2 is much better than gcc3 for most routines, so gcc may be the best compiler there now as well."

              Мы тоже уже почти отказались от использования ICC и перешли на GCC 4.2 (причём не факт что все вещи которые всё ещё компилируются ICC таки реально быстрее)... Легко верю в то что Oracle, скомпилированный ICC работает реально быстрее (ибо ICC под Oracle очень хорошо заточен), но вот насчёт программ создаваемых "простыми смертными" - тут всё сложнее...
                +1
                Для простых смертных есть python, ruby и много других скриптовых языков. Правда, это только в том случае если производительность для вас не сильно критичный параметр.
                • UFO just landed and posted this here
                    0
                    Эмс. Мы пользуемся ATLAS'ом на наших суперкомпьютерах, уж не знаю, как сами авторы производительность меряли, но у нас она поднимается при использовании компилятора от PGI на Opteron'ах, и при использовании icc на x86. Но это не показатель, известно, что компиляторы и на ATLAS натаскивают, и на LAPACK, и на LINPACK, потому что ими меряют производительность суперкомпьютеров. Но это не означает, что они и с другими кодами хорошо справляются. Потому что натаскивание идёт чисто по шаблонам, по крайней мере для GCC это так. По слухам, и для компиляторов Intel тоже.
                      0
                      Читайте внимательнее, позиция ATLAS такова: icc быстрее, но не "аккуратнее", а gcc — самый быстрый из "аккурантных" (т.е. IEEE FP compilant). Конечно, вы можете компилировать icc, если вам всё равно, какие циферки выдаст программа :)
                        0
                        Хм. Вся 'аккуратность' gcc заключается в том, что он использует x87, а не SSE2 - 80 битную арифметику, а не 64 битную. Если отключить соответсвующую оптимизацию в icc, то цифры на тестах выходят одинаковые.

                        p.s. ieee fp - это стандарт на арифметику, а не на поведение компилятора.
                          0
                          1. Может быть. Но разработчики ATLAS считают иначе.
                          2. По поводу P.S. Высказывание, конечно, верное, но почитайте, что написано об опциях -ffloat-store и -ffast-math. Компилятор может такого наоптимизировать, что вместо результата будет погода на Марсе.
                  0
                  А причем тут Linux? Не уверен, что Linux когда нибудь перейдет на новый компилятор. Столько лет ушло на переход на новую систему контроля версий, и в результате Линус начал сам разрабатывать свою систему контроля :) Получается, что если убедить Линуса перейти на другой компилятор, годкам так к 70, он перейдет на собственноручно написанный компилятор! :) И вообще если не нравится GCC есть другие компиляторы.


                  У GCC свой путь. Коллекция компиляторов собирается на множестве платформ, это во первых! Все современные *nix системы собираются на нем, это блин, реальность! Среди этих систем множество коммерческих *nix систем. Тот же Silicon Graphics или X Mac OS. Но это не единственные разработчики компилятора. И даже не разработчики, скорее, патчеписатели :). Основная команда разработчиков связана с разработкой GNU OS и сопутствующего инструментария. Это Grub, Qemu и прочее. И кстати, Linux не вписывается в эту категорию. К сожалению в GNU OS ему нет места :\

                  Вообще, лично я за разнообразие, и поэтому поддерживаю эту иннициативу. Если на почве ненависти GNU есть возможность привлечь энтузиастов к разработке важного, сложного и нужного инструмента, то что же еще может быть еще лучше? :)

                  В любом случае GCC не стандарт, стандарт C, C++ и остальные.
                  • UFO just landed and posted this here
                      0
                      Чего такого плохого в коммунизме?
                      • UFO just landed and posted this here
                          0
                          Деньги и есть насилие над личностью. Банки дают 10 игрокам 10 кредитов по 10 миллионов и говорят, принесите через год по 11 миллионов. Как ты думаешь это может стать причиной насилия?
                          • UFO just landed and posted this here
                              0
                              Откуда? Денежная система замкнута на себя и денежная масса конечна, я для примера взял что всего 100млн. В реальности общее количество денег больше и игроков тоже не 10. В игру вовлечено множество играков. Но принцип пронцентной ставки остается инструментом стричь капусту владельцу денежной системы.

                              При такой системе каждый участник должен заработать 1млн забрав его у одного из остальных. Т.е. на момент отдачи кредита происходят всякие задержки и тд. участники не выплатившие в данный момент начинают выплачивать пени. Все это приводит к задолжности которую потребуют судебные приставы :\
                              • UFO just landed and posted this here
                                  0
                                  Это отлиное описание проблем: вся современная денежная система жёстко завязана на бесконечное расширение. А если вдруг мы упрёмся в ограниченность планеты Земля (а это таки случится и случится скоро), то вся финансовая система слетит с катушек и начнётся то, что описывает cyberzx...
                                  • UFO just landed and posted this here
                                    0
                                    Нифига, количество денег ограниченно. И даже если вдруг от пятен на солнце все станут больше работать и произведут больше товаров, то это не увеличит денежную массу. Денежной массой управляет правительство.

                                    Для увеличения массы они выпустят новые купюры и расплатятся ими за товары. Но инфляция всегда меньше процентной ставки!. Т. Е. инфляция связанная с увеличением количества денег никогда не приведет к убыткам банков.
                                    0
                                    >Денежная система замкнута на себя и денежная масса конечна,
                                    угу, Якутские алмазы (карьеры) уже давно посчитаны и банк на них бумажек наклепал.

                                    >Законы сохранения действуют лишь для закрытых систем.
                                    истинно так!
                              0
                              Капиталим - это эксплуатация человека человеком, а коммунизм - наоборот!
                                0
                                Эксплуатация человеком человека?
                              0
                              Торвальдс сейчас пропагандирует не "just for fun", а политику аля "пишите то, что востребованно".
                              Мне это не особо по душе.
                                0
                                Так пишите just for fun ;)
                                Кто же запрещает?
                                • UFO just landed and posted this here
                                0
                                Ну, Linux community. Оно от GCC очень сильно зависит, потому что другим компилятором ядро не откомпилировать. Ну да, и уж точно перейти на другой компилятор им сейчас будет стоит огромных затрат.
                                0
                                Больше компиляторов хороших и разных, но по-моему тут еще и "лишь бы не GNU". Сам я пользовался GCC для сборки linux под arm, было здорово (даже удобно несмотря на некоторый бардак openembedded) и мне много чего говорил вывод -Wall.
                                  0
                                  Просто автор - один из тех людей, которые "кладут" на warning-и.
                                  По большей части, warnings полезны и помогают отследить некоторые ошибки.
                                  0
                                  по пунктам:
                                  1) fud
                                  2) Warning-и сообщают о всех местах непонятных компилеру и/или несоответствиях стандарту.
                                  Лично я стараюсь чтобы компилилось без warning-ов.
                                  Хотя я всё же вырубил warning на отсутствие переноса строки в конце файла, т.к. ИМХО это полный бред (хотя и положено по стандарту)

                                  4) Это кончится тем, что они сделают gcc #2
                                  3&5) На счёт внутренностей согласен. Это просто ужас какой-то! Приходилось править баг в sparc backend в gcc3.4.6. Хотел также подпилить pipehole optimizer, но после перелома извилины плюнул на это дело.

                                  PS: Скачал исходники этого pcc - 300kb в gz - это всё чтоли?
                                    0
                                    Не сказал бы, что код GCC прямо уж очень кривой. В совсем глубоких слоях мозгов копаться не приходилось, но дополнительный оптимизационный проход на уровне деревьев (GIMPLE) закодить оказалось несложно совсем.
                                      0
                                      Введение GIMPLE в GCC 4.0 - это как раз попытка сделать код чуть проще и понятнее. До этого вся оптимизация производилась только в RTL. Посмотрим что OpenBSD'шники с PCC сделают: там, конечно, крутые ребята, но их мало, так что вряд ли можно ожидать сурьезных улучшений PCC в ближайшем будущем...
                                        +1
                                        У них неправильный подход. Не надо брать какой-то тухлый компилятор, а надо брать какой-нибудь мощный, но быстрый современный язык программирования типа O'Caml и писать на нём.

                                        Пару лет назад пролетало сообщение (не на хабре), что какой-то паренёк из Бразилии написал за три месяца на Haskell компилятор C. А вам слабо?
                                          0
                                          Я имею в виду писать на O'Caml компилятор C, а не писать операционку. Хотя это тоже вариант :)
                                            0
                                            С другой стороны, это может ограничить портабельность самого компилятора...

                                      Only users with full accounts can post comments. Log in, please.