Экспериментаторы с ресурса Phoronix дополнили опубликованное (http://www.opennet.ru/opennews/art.shtml?num=26283) в понедельник сравнение производительности компиляторов GCC (4.3 (http://www.opennet.ru/opennews/art.shtml?num=14584), 4.4 (http://www.opennet.ru/opennews/art.shtml?num=21376), 4.5 (http://www.opennet.ru/opennews/art.shtml?num=26233)) и опубликовали (http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_...) более полный отчет, в котором отражены результаты измерения производительности Clang (http://www.opennet.ru/opennews/art.shtml?num=25305) и LLVM-GCC (http://www.opennet.ru/opennews/art.shtml?num=23985). Напомню, что в рамках проекта LLVM ведется разработка GCC совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный байткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный платформонезависимый псевдокод может быть преобра...URL: http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_...
Новость: http://www.opennet.ru/opennews/art.shtml?num=26314
Ну и к чему все эти баяны, когда gcc по прежнему быстр, поддерживает больший спектр аппаратных платформ и более полно поддерживает спецификации языков?
Он под некошерной, по мнению BSD-сообщества, лицензией.
А что вы понимаете под кошерностью?
BSD-сообщество занимается подготовкой кода, предназначенного для включения в проприетарные проекты. Поэтому кошерность = возможность не открывать сорцы.
Очень тонко, браво!
Ну по сравнению с сообществои GPL которое занимается подготовкой среды для выполнения бинарных блобов от больших корпораций - мы таки просто ангелы :)PS: Ещё более тонко ...
Ещё более тонко ...
>мы таки просто ангелы :)Только местом обитания таких "ангелов" являются почему-то ... пещеры, сами "ангелы" как правило толстоваты, любят покушать, нимба нет а в руках почему-то дубинка. Вот такие вот хреновые нынче ангелы... :P
p.s. что минусуете, пещерные? Правда глаза колет? А может нимб жмет? :)
ну да, зачем нужны 16-ядерные оптероны, когда на моем компе и 4-ядерный не загружен...
сlang еще в стадии развития, что будет после того, как он проживет хотя бы 1/10 от gcc - еще вопрос.
Clang начали пилить с 2005го судя по wiki. Так что ему уже 5 лет, а gcc - 25.
>ну да, зачем нужны 16-ядерные оптероныТаких пока нет. В 6100 series(Magny-Cours) максимум 12 ядер.
зачем же делают LLVM-GCC если "тоже самое" на жаве-JIT "тормозит в 3 раза" ? может и в жаве не "язык кривой" а программисты пишут не задумываясь ?
>на жаве-JIT "тормозит в 3 раза"_Большинство_ пишут не задумываясь из-за автоматического управления памяти. Вот это автомат в яве и тормозит. Такия вот "безопасные" языки выращивают безответственных программеров.
автоматическое распределение памяти и были придумано чтобы избежать ошибок при работе с ней. наобщать наобещали а для той же жавы по нормальному так и не сделали. вот и приходится самому следить за памятью.
>автоматическое распределение памяти и были придумано чтобы избежать ошибок при работе с
>ней.Ну, стали течь объекты которые забыли освободить вместо массивов памяти. В итоге сильно лучше не стало, а к ошибкам в программе добавились ошибки в 100-меговом рантайме (коих как грязи в такой массе кода). В том числе и куча по части секурити, если уж на то пошло. Вон например запускач явы из веба позволял запускать вообще что попало с правами текущего юзера. Безопаснее некуда, ага. Вообще, есть такое подозрение что как безбашенных дебилов не строй - а они всегда найдут где облажаться. Ну вон веб приложения. Ну, нет там управления памяти. Что, стало лучше? А вот и хрен вам. То инклуды левых файлов, то sql-иньекции, то XSS... и в итоге как-то никто не стал чувствовать себя сильно защищеннее, а вопли хомячков вида "гугл взломали" уже начинают становиться привычными, чтоли. Может быть отстоен не язык а криворукие программисты, а? При том криворуких которые юзают си/си++ к счастью осталось немного, криворукие сбежали на явы, дельфи и прочие дотнеты за быстрым баблом клепать г-нецо бизнесу :)
ты что сказать то хотел?
я писал про то что раз обещали сделать автоматическую сборку мусора-сделайте качественно или вообще уберите ее
Мне кажется Вы не компетентны в том, о чем говорите.
+1 но спорить с ними бесполезно..
>_Большинство_ пишут не задумываясь из-за автоматического управления памяти. Вот это автомат в
>яве и тормозит. Такия вот "безопасные" языки выращивают безответственных программеров.мне кажется что из-за того что в жаве легко программировать верхними представлениями не особо зная что кроется внутри и не особо представляя на сколько они оптимальны и оверхедны для задач программиста и получается торможение
вероятно компилятор и JIT не на столько круты чтоб выкидывать всё неиспользуемое в программе этого прогера
т.е. если идиот пишет на жаве то все тормозит, а если на другом языке то нет?
По пробуй на ADA замутить глючную прогу :)
Погугли про Ариан-5 и как его завалила малюсенькая программка на языке который прям таки не позволяет ваять глючгый код ... :)
>Ути пуси! :) Ыксперты жгутЪ!(С)
>
>Погугли про Ариан-5 и как его завалила малюсенькая программка
> на языке который прям таки не позволяет ваять глючгый код ... :):)
Мы говорили про идиотов, а не про слепых программистов, путающих "." и ","
А какая разница на чём пишет идиот?! Результат по любому на 100% предсказуем. Ну и чего о них говорить то?
>т.е. если идиот пишет на жаве то все тормозит, а если на другом языке то нет?если идиот пишет на Сях то пока он сможет запустить свою программу - вероятно он чему-то научится )) или его программа работать будет как 4.0 кеды :)
Да пофиг не чём написано! Главное кем и как.
Есть "в одном высокогорном селении Простоквашино" Гор. СЭС для которой в ~1993 году старший детёнок главбуха написал какую то автоматизацию ... не за деньги даже, а за то что ночью ему давался доступ с писюку. Так вот - у них давно уже свой IT отдел, и все они хором заявляют что это единственная прога которая "просто работает" и пережила DOS->Win3.*->Win9?->WinNT4->Win200 ...Так вот - оно на MS GW-BASIC! Ога - на том самом, с "кошмарными goto" ;-)
> ... ~1993 году старший детёнок главбуха написал какую то автоматизацию ...
> и все они хором заявляют что это единственная прога которая "просто работает"Кстати, трехколесный велосипед "Малыш", тоже средство передвижения.
>Кстати, трехколесный велосипед "Малыш", тоже средство передвижения.Хе-хе :)
Кстати с точки зрения ребятёнка на нём рассекающего - абсолютно так :)
Это потом когда вырастет начнётся - "вазнемашинапапдайденегнабэху" ...
Реальный тест-если собрать всю сисетму каждым из компалеров и поработать в ней некоторое время
Отчёт какой-то бестолковый. "В тесте флипфлопхрюп 432.65.7 clang оказался медленнее gcc" - НУ И ЧТО? В чём смысл теста-то? Интересно увидеть конкретные тестируемые фичи - плавающую точку, создание объектов, вызовы функций... Заодно будет видно, что подкрутить в clang. Мне кажется, за clang будущее, т.к. он более модульный и современный, просто ещё не очень отполированный. Заодно это создаёт платформу для переноса других языков (а не прикручивать их сбоку как в gcc).
Фороникс же..
а более внятные сообщения об ошибках уже не преимущество clang? LTO, впрочем, он есть в gcc45 и llvm-gcc. Да и phoronix как всегда троллит:> GCC 4.5 is taking more time to compile programs *likely* due to the LTO support and other new features,
likely? т.е. они даже не знают включили ли он его? clang и llvm-gcc тоже, наверное, компилят без LTO. Fail.
Ах да, лучше бы сравнивали XZ (Си) вместо 7zip (Си++). Си-код лучше оптимизируется.
>Ах да, лучше бы сравнивали XZ (Си) вместо 7zip (Си++). Си-код лучше оптимизируется.Хороший Cи-код вообще не оптимизируется :)
Даже хороший код оптимизируется, но на более низком уровне. Естесственно, кривую архитектуру программы никакой компилятор не соптимизирует и не исправит ;)
>Хороший Cи-код вообще не оптимизируется :)На оптимирацию "хорошего сишного" потрачены минуты и часы жизни программиста, а на оптимизацию "не-хорошего" -- секунды-минуты компилятора. "А если не видно разницы..."
>>Хороший Cи-код вообще не оптимизируется :)
>
>На оптимирацию "хорошего сишного" потрачены минуты и часы жизни программиста, а на
>оптимизацию "не-хорошего" -- секунды-минуты компилятора.
> "А если не видно разницы..."То PHP и .Net правит миром. (по закону - ошибки не суммируются, а умножаются)
>>Хороший Cи-код вообще не оптимизируется :)
>
>На оптимирацию "хорошего сишного" потрачены минуты и часы жизни программиста, а на
>оптимизацию "не-хорошего" -- секунды-минуты компилятора. "А если не видно разницы..."Компилятор не может оптимизировать логические ляпы.
Например:for (охренительный цикл)
{
инициализация одних и тех же переменных;вычисление;
}Когда инициализацию нужно выносить ДО for.
>Компилятор не может оптимизировать логические ляпы.Исправление ошибок и оптимизация -- таки разные вещи, совсем. Начитайте оптимизировать свою логическую ошибку. Не при всех же ж, pls%%%
>Например:
>for (охренительный цикл)
>{
> инициализация одних и тех же переменных;
> вычисление;
>}
>Когда инициализацию нужно выносить ДО for.И да, компиляторы это давно делают, я полагаю............
> а более внятные сообщения об ошибках уже не преимущество clang?Ну они там сказали, что не все отличия между компиляторами можно выразить числами.
> Ах да, лучше бы сравнивали XZ (Си) вместо 7zip (Си++). Си-код лучше оптимизируется.
Код не оптимизируется, оптимизируется промежуточное представление.
>> а более внятные сообщения об ошибках уже не преимущество clang?
>Ну они там сказали, что не все отличия между компиляторами можно выразить
>числами.
>> Ах да, лучше бы сравнивали XZ (Си) вместо 7zip (Си++). Си-код лучше оптимизируется.
>Код не оптимизируется, оптимизируется промежуточное представление.Не придирайся, имеется в виду те фишки, которые доступны на процессоре,
типа разворачивание циклов, векторизация, оптимизация условных переходов - likely()/unlikely(),
с флотами/даблами - непроверка на переполнения и div/0, всякие предсказания,
сache-hits, inline/uninline и т.п.Собственно, никто не мешает всё это провернуть в ручную.
>В целом LLVM / Clang не оправдали возложенные на них ожиданияКем возложенные? Какие ожидания?
Сравните количество людей, которые работают над gcc и clang, и время, которое они развивались.
поддерживаю, странное заявление
Создателями конечно. Например, "Fast compiles and Low Memory Use"
http://clang.llvm.org/features.html#enduser
Ну эти-то он оправдал.
>Создателями конечно. Например, "Fast compiles and Low Memory Use"
>http://clang.llvm.org/features.html#enduserНу да, сейчас памяти просто не хватает... а 12-ядерные процессоры не могут откомпилировать "hello world" за приемлемое время.
Сравнивать надо скорость и качество получившихся программ, а не компиляторов.
>Сравнивать надо скорость и качество получившихся программ, а не компиляторов.Именно так!
Apple
Ну это Фороникс+Опеннет высказывание, кто там чего ожидал не ясно.
Кому-то просто очень стало больно в попе от антипиара gcc.
Ага - опять скорость измерялась количеством FPS в запущенной в паралель игрухе?
форониксы же! :)
Интересно, а бойцам из фороникса вводный курс 'обработка экспериментальных данных' никто не предлагал прочитать?
Хотел бы ,где-нибудь, увидеть структуру "виртуального процессора" от GCC и Clang.
А так непонятно вчем новизна ?
В общем : если Clang более эффективен, буду компилировать Linux в Сlang.
Линцензии дома меня не волнуют.
>В общем : если Clang более эффективен, буду компилировать Linux в Сlang.FreeBSD-шнеги делают. Даже ядро и мир им собранные уже бутятся :)
FreeBSD-шнеги делают. Даже ядро и мир им собранные ужо бутятся :)
Большое спасибо. Но пока сбегаю на Debian качнуть KFREEBSD.
Вроде есть 3d-поддержка к древнему Mach64 (очень актуально).
А там видно будет.
Они видимо решили забить на все float-ы в программах и стандарте C99, улучшение поддержки которого сильно замедлило компиляцию таких программ. Компилировали бы с -fexcess-precision=fast -- получили бы ускорение в компиляции.
А -fexcess-precision=fast только компиляцию ускоряет или выполнение кода -- тоже?