Комментарии 45
перевод: mikhanoid
Да, действительно, механоид...
комментарии от себя может быть как-нибудь выделить? например, курсивом.
По субжу:
Portable C Compiler это же по-моему нечто очень древнее. Они хотят его возрадить и развить до уровня теперешнего GCC? GNU Compiler Collection можно ругать, но работа по созданную нечто подобного потребует огромного колличества человека времени и инвестиций. Ведь как правильно замечено gcc сейчас развивается отнюдь не энтузиастами.
По субжу:
Portable C Compiler это же по-моему нечто очень древнее. Они хотят его возрадить и развить до уровня теперешнего GCC? GNU Compiler Collection можно ругать, но работа по созданную нечто подобного потребует огромного колличества человека времени и инвестиций. Ведь как правильно замечено gcc сейчас развивается отнюдь не энтузиастами.
Он начался давно, но его поддерживают. Я посмотрел исходники, там есть тексты, датированные 2003 годом.
Конечно, для разработки нового GCC понадобиться столько же усилий, но нужно ли разрабатывать нечто подобное GCC? Лично я не сомневаюсь, что есть способы организовать набор компиляторов намного более простым способом, соответсвенно, и разработать его можно быстрее. Тем более, если не требовать полной совместимости с GCC, в котором немало особенностей. Пример этому - компиляторы в Plan9.
Конечно, для разработки нового GCC понадобиться столько же усилий, но нужно ли разрабатывать нечто подобное GCC? Лично я не сомневаюсь, что есть способы организовать набор компиляторов намного более простым способом, соответсвенно, и разработать его можно быстрее. Тем более, если не требовать полной совместимости с GCC, в котором немало особенностей. Пример этому - компиляторы в Plan9.
А тем временем 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 уже давно решили что "оно им не надо", то выбор выглядит разумным: какой смысл возиться со сложными и неоднозначными инструментами если предоставляемые ими преимущества тебя просто не волнуют ?
Что касается сложности компилятора, то 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 уже давно решили что "оно им не надо", то выбор выглядит разумным: какой смысл возиться со сложными и неоднозначными инструментами если предоставляемые ими преимущества тебя просто не волнуют ?
В FreeBSD как-то хотели open watcom импортировать.
Не открою Америку через форточку если скажу, что GCC это самый плохой ныне существующий компилятор, конечно, кроме всех остальных:)
Вижу, что хабралюди имеют хорошую привычку читать только по пол-предложения. Ну-ну, в том же духе:)
Просто очень криво мысль сформулировал.
Да не - просто люди в Интернете не имеют привычки вдумчиво читать что-либо. А журналисты всполошились: дескать не хотим для роботов писать! Только вот в случае постоянного цейтнота люди воспринимают "заумные" фразы ничуть не лучше роботов, что и показал проведённый ytsuken'ым эксперимент...
НЛО прилетело и опубликовало эту надпись здесь
Давно сравнивали ? Разработчики 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 очень хорошо заточен), но вот насчёт программ создаваемых "простыми смертными" - тут всё сложнее...
Мы тоже уже почти отказались от использования ICC и перешли на GCC 4.2 (причём не факт что все вещи которые всё ещё компилируются ICC таки реально быстрее)... Легко верю в то что Oracle, скомпилированный ICC работает реально быстрее (ибо ICC под Oracle очень хорошо заточен), но вот насчёт программ создаваемых "простыми смертными" - тут всё сложнее...
Для простых смертных есть python, ruby и много других скриптовых языков. Правда, это только в том случае если производительность для вас не сильно критичный параметр.
НЛО прилетело и опубликовало эту надпись здесь
Эмс. Мы пользуемся ATLAS'ом на наших суперкомпьютерах, уж не знаю, как сами авторы производительность меряли, но у нас она поднимается при использовании компилятора от PGI на Opteron'ах, и при использовании icc на x86. Но это не показатель, известно, что компиляторы и на ATLAS натаскивают, и на LAPACK, и на LINPACK, потому что ими меряют производительность суперкомпьютеров. Но это не означает, что они и с другими кодами хорошо справляются. Потому что натаскивание идёт чисто по шаблонам, по крайней мере для GCC это так. По слухам, и для компиляторов Intel тоже.
Читайте внимательнее, позиция ATLAS такова: icc быстрее, но не "аккуратнее", а gcc — самый быстрый из "аккурантных" (т.е. IEEE FP compilant). Конечно, вы можете компилировать icc, если вам всё равно, какие циферки выдаст программа :)
А причем тут Linux? Не уверен, что Linux когда нибудь перейдет на новый компилятор. Столько лет ушло на переход на новую систему контроля версий, и в результате Линус начал сам разрабатывать свою систему контроля :) Получается, что если убедить Линуса перейти на другой компилятор, годкам так к 70, он перейдет на собственноручно написанный компилятор! :) И вообще если не нравится GCC есть другие компиляторы.
У GCC свой путь. Коллекция компиляторов собирается на множестве платформ, это во первых! Все современные *nix системы собираются на нем, это блин, реальность! Среди этих систем множество коммерческих *nix систем. Тот же Silicon Graphics или X Mac OS. Но это не единственные разработчики компилятора. И даже не разработчики, скорее, патчеписатели :). Основная команда разработчиков связана с разработкой GNU OS и сопутствующего инструментария. Это Grub, Qemu и прочее. И кстати, Linux не вписывается в эту категорию. К сожалению в GNU OS ему нет места :\
Вообще, лично я за разнообразие, и поэтому поддерживаю эту иннициативу. Если на почве ненависти GNU есть возможность привлечь энтузиастов к разработке важного, сложного и нужного инструмента, то что же еще может быть еще лучше? :)
В любом случае GCC не стандарт, стандарт C, C++ и остальные.
У GCC свой путь. Коллекция компиляторов собирается на множестве платформ, это во первых! Все современные *nix системы собираются на нем, это блин, реальность! Среди этих систем множество коммерческих *nix систем. Тот же Silicon Graphics или X Mac OS. Но это не единственные разработчики компилятора. И даже не разработчики, скорее, патчеписатели :). Основная команда разработчиков связана с разработкой GNU OS и сопутствующего инструментария. Это Grub, Qemu и прочее. И кстати, Linux не вписывается в эту категорию. К сожалению в GNU OS ему нет места :\
Вообще, лично я за разнообразие, и поэтому поддерживаю эту иннициативу. Если на почве ненависти GNU есть возможность привлечь энтузиастов к разработке важного, сложного и нужного инструмента, то что же еще может быть еще лучше? :)
В любом случае GCC не стандарт, стандарт C, C++ и остальные.
НЛО прилетело и опубликовало эту надпись здесь
Чего такого плохого в коммунизме?
НЛО прилетело и опубликовало эту надпись здесь
Деньги и есть насилие над личностью. Банки дают 10 игрокам 10 кредитов по 10 миллионов и говорят, принесите через год по 11 миллионов. Как ты думаешь это может стать причиной насилия?
НЛО прилетело и опубликовало эту надпись здесь
Откуда? Денежная система замкнута на себя и денежная масса конечна, я для примера взял что всего 100млн. В реальности общее количество денег больше и игроков тоже не 10. В игру вовлечено множество играков. Но принцип пронцентной ставки остается инструментом стричь капусту владельцу денежной системы.
При такой системе каждый участник должен заработать 1млн забрав его у одного из остальных. Т.е. на момент отдачи кредита происходят всякие задержки и тд. участники не выплатившие в данный момент начинают выплачивать пени. Все это приводит к задолжности которую потребуют судебные приставы :\
При такой системе каждый участник должен заработать 1млн забрав его у одного из остальных. Т.е. на момент отдачи кредита происходят всякие задержки и тд. участники не выплатившие в данный момент начинают выплачивать пени. Все это приводит к задолжности которую потребуют судебные приставы :\
НЛО прилетело и опубликовало эту надпись здесь
Это отлиное описание проблем: вся современная денежная система жёстко завязана на бесконечное расширение. А если вдруг мы упрёмся в ограниченность планеты Земля (а это таки случится и случится скоро), то вся финансовая система слетит с катушек и начнётся то, что описывает cyberzx...
Нифига, количество денег ограниченно. И даже если вдруг от пятен на солнце все станут больше работать и произведут больше товаров, то это не увеличит денежную массу. Денежной массой управляет правительство.
Для увеличения массы они выпустят новые купюры и расплатятся ими за товары. Но инфляция всегда меньше процентной ставки!. Т. Е. инфляция связанная с увеличением количества денег никогда не приведет к убыткам банков.
Для увеличения массы они выпустят новые купюры и расплатятся ими за товары. Но инфляция всегда меньше процентной ставки!. Т. Е. инфляция связанная с увеличением количества денег никогда не приведет к убыткам банков.
>Денежная система замкнута на себя и денежная масса конечна,
угу, Якутские алмазы (карьеры) уже давно посчитаны и банк на них бумажек наклепал.
>Законы сохранения действуют лишь для закрытых систем.
истинно так!
угу, Якутские алмазы (карьеры) уже давно посчитаны и банк на них бумажек наклепал.
>Законы сохранения действуют лишь для закрытых систем.
истинно так!
Капиталим - это эксплуатация человека человеком, а коммунизм - наоборот!
Торвальдс сейчас пропагандирует не "just for fun", а политику аля "пишите то, что востребованно".
Мне это не особо по душе.
Мне это не особо по душе.
Ну, Linux community. Оно от GCC очень сильно зависит, потому что другим компилятором ядро не откомпилировать. Ну да, и уж точно перейти на другой компилятор им сейчас будет стоит огромных затрат.
Больше компиляторов хороших и разных, но по-моему тут еще и "лишь бы не GNU". Сам я пользовался GCC для сборки linux под arm, было здорово (даже удобно несмотря на некоторый бардак openembedded) и мне много чего говорил вывод -Wall.
по пунктам:
1) fud
2) Warning-и сообщают о всех местах непонятных компилеру и/или несоответствиях стандарту.
Лично я стараюсь чтобы компилилось без warning-ов.
Хотя я всё же вырубил warning на отсутствие переноса строки в конце файла, т.к. ИМХО это полный бред (хотя и положено по стандарту)
4) Это кончится тем, что они сделают gcc #2
3&5) На счёт внутренностей согласен. Это просто ужас какой-то! Приходилось править баг в sparc backend в gcc3.4.6. Хотел также подпилить pipehole optimizer, но после перелома извилины плюнул на это дело.
PS: Скачал исходники этого pcc - 300kb в gz - это всё чтоли?
1) fud
2) Warning-и сообщают о всех местах непонятных компилеру и/или несоответствиях стандарту.
Лично я стараюсь чтобы компилилось без warning-ов.
Хотя я всё же вырубил warning на отсутствие переноса строки в конце файла, т.к. ИМХО это полный бред (хотя и положено по стандарту)
4) Это кончится тем, что они сделают gcc #2
3&5) На счёт внутренностей согласен. Это просто ужас какой-то! Приходилось править баг в sparc backend в gcc3.4.6. Хотел также подпилить pipehole optimizer, но после перелома извилины плюнул на это дело.
PS: Скачал исходники этого pcc - 300kb в gz - это всё чтоли?
Не сказал бы, что код GCC прямо уж очень кривой. В совсем глубоких слоях мозгов копаться не приходилось, но дополнительный оптимизационный проход на уровне деревьев (GIMPLE) закодить оказалось несложно совсем.
Введение GIMPLE в GCC 4.0 - это как раз попытка сделать код чуть проще и понятнее. До этого вся оптимизация производилась только в RTL. Посмотрим что OpenBSD'шники с PCC сделают: там, конечно, крутые ребята, но их мало, так что вряд ли можно ожидать сурьезных улучшений PCC в ближайшем будущем...
У них неправильный подход. Не надо брать какой-то тухлый компилятор, а надо брать какой-нибудь мощный, но быстрый современный язык программирования типа O'Caml и писать на нём.
Пару лет назад пролетало сообщение (не на хабре), что какой-то паренёк из Бразилии написал за три месяца на Haskell компилятор C. А вам слабо?
Пару лет назад пролетало сообщение (не на хабре), что какой-то паренёк из Бразилии написал за три месяца на Haskell компилятор C. А вам слабо?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
новый компилятор в OpenBSD