Ресурс Phoronix провёл (http://www.phoronix.com/scan.php?page=article&item=llvm_32_e...) оценку производительности тестовых приложений, собранных с использованием различных современных версий компиляторов Clang и GCC. В сравнении приняли участие Clang 3.1, SVN версия Clang 3.2, GCC 4.7.2, версия GCC 4.8, находящаяся в разработке, а также GCC с плагином DragonEgg, который позволяет GCC использовать LLVM в качестве бэкэнда.
В большинстве тестов победил GCC, при том в некоторых тестах отличия достигали нескольких раз (отдельно подчеркивается, что ряд результатов не связан с поддержкой OpenMP). Тем не менее, в нескольких тестах (несколько тестов набора SciMark) Clang выиграл с заметным отрывом. Связка GCC + DragonEgg показала достаточно неоднозначные результаты, местами выигрывая у вообще всех участников тестирования, но сильно проиграв в некоторых других тестах всем участникам.URL: http://www.phoronix.com/scan.php?page=article&item=llvm_32_e...
Новость: https://www.opennet.ru/opennews/art.shtml?num=35292
Let the срач begin!
> Let the срач begin!всем пофигу
(а не только тебе :))
> Let the срач begin!
не так. Да нечнется великое обсуждение новейших конпелятороф!!
Может лучше лицензии обсудить - это более продуктивно.
> Может лучше лицензии обсудить - это более продуктивно.лучше qt vs gtk
Лучше dr dos vs ms dos.Хоть посмотрим, как куча людей, абсолютно не представляющих, о чём речь, будут доказывать преимущество одного перед другим. Хотя, конечно, мы такие споры видим ежедневно и во многих экземплярах.
dr-dos лучше, там была netwars и поддержка нетвари искаропки.
Ваш ход.
* большая совместимость, некоторые приложения работали ТОЛЬКО в msdos, благодаря своим особенностям* в msdos до 5 версии был dosshell, с темами. красотища на тот момент несусветная! :)
* в msdos до 5 или до 6 версии был qbasic! и гориллы, первая серьёзная opensource-игра в моей жизни :) это, конечно, не netwars и не перевешивает преимущества filelink (хотя тогда у каждого уважающего себя был нортон), зато opensource (хотя drdos потом вся стала opensource).
* и, главное: если бы cadlera (впоследствии ставшая SCO) не купила бы dr dos, и не подала бы на microsoft в суд за то, что их ms dos нарушает патенты, то microsoft не похвалила их за ОТЛИЧНУЮ ИДЕЮ.
1. DOS Shell был во всех версиях MSDOS, на доп. дискетке.
2. Не cadlera, а Caldera
3. Santa Cruz Operation (SCO) родились в 1979, когда у Торвальдыца ещё не стоял.
(Santa Cruz Operation и The SCO Group не одно и тоже).
DR.DOS - кривое уйобищо, на котором не работало 90% 32-битных программ,
TCP/IP стек глючил, NETBEUI, дров для сетевух мало было,...
> DR.DOS - кривое уйобищо, на котором не работало 90% 32-битных программ,+1 4DOS over PC-DOS - наше фсёё
Ну то, что вас из всего этого больше всего интересует, что там стояло у Торвальдса, я и не сомневался. Ориентация - это то, что всегда выдавало ярых фанатов microsoft и apple.> 1. DOS Shell был во всех версиях MSDOS, на доп. дискетке.
В 7 не было, в 3.3 тоже не было, это точно. Появилась в 4 или в 5, и первые версии windows были уж больно на неё похожи. :) И там был ТАЙЛИНГ! :)
> DR.DOS - кривое уйобищо, на котором не работало 90% 32-битных программ,Ага.
> TCP/IP стек глючил, NETBEUI, дров для сетевух мало было,...
Зато там была нормальная полноценная сеть из коробки, при отключении всех химемов можно в дум гонять, tcp/ip тогда вообще мало кому нужен был.
>> 1. DOS Shell был во всех версиях MSDOS, на доп. дискетке.
> В 7 не было, в 3.3 тоже не было, это точно. Появилась
> в 4 или в 5,MS DOS 7 - не было!
> MS DOS 7 - не было!Был. В 9х виндах. Они же над досом грузились. Дос 7.х вполне себе мог запускаться и сам по себе. Ну, обычный такой дос с некоторыми улучшениями.
>> MS DOS 7 - не было!
> Был.В википедии и 8.0 _был_. Однако же павлин имеет возможность отмазаться, что "в коробочке" не был. Обсудили! Молодцы!
ms-dos была клоном cp/m. изначально q-dos точно не помню. dr-dos также создана Гарри Килдаллом. темная не красивая история. миф созданный ibm и microsoft.
> ms-dos была клоном cp/m. изначально q-dos точно не помню. dr-dos также создана
> Гарри Килдаллом. темная не красивая история. миф созданный ibm и microsoft.Да. Но деньги уже попилены.
Пользовался тремя версиями MS-DOS.
После чего хорошо понимал, почему MS-рекламщики так пугают пользователей "голой командной строкой". Именно потому, что "командная строка" от MS - и голая, и ужасная притом...
> Именно потому, что "командная строка" от MS - и голая, и ужасная притом...Что самое интересное, оно сильно лучше с тех пор не стало. Например автодополнение у MS по прежнему работает хуже чем в любом даже самом древнем *nix-like.
По-моему, это как преимущества слепого перед глухим...
gcc это как IE с CSS hack's
А что ИЕ умел работать везде и собирать всё?
> А что ИЕ умел работать везде и собирать всё?Нет. Аналогия в том, что его разработку Apple тоже не контролировала.
> Нет. Аналогия в том, что его разработку Apple тоже не контролировала.Дожили, троллинг настолько толст и бездарен что надо отдельно объяснять что это вообще троллинг :)
как раз наоборот очень тоненький был, помоему
> gcc это как IE с CSS hack'sТолсто и уныло. Попробуйте еще раз.
В сухом остатке Clang медленнее компилирует, программы собранные им медленнее работают, хуже поддержка c++11, LLVM поддерживает меньше языков...
А столько пафоса было, столько пафоса.
Жалко только freeBSD, она и так то еле загружалась, а с переходом на CLANG...
Да быстрее он компилирует, быстрее. На глаз вообще кажется раза в два быстрее, с секундомером не проверял.
Ну вообще, то во freeBSD использовался GCC 4.2.1, он в тестирование участие не принимал, так что кто быстрее GCC 4.2.1 и Clang 3.2 ,я сказать не могу. И никто, во FreeBSD поддержу GCC не убирал - будет в портах.
> он в тестирование участие не принималПотому что объем продукции завода Форда относительно 1929 года мало кого интересует. Вот как он сегодня с конкурентами соотносится - уже интереснее.
>> он в тестирование участие не принимал
> Потому что объем продукции завода Форда относительно 1929 года мало кого интересует.
> Вот как он сегодня с конкурентами соотносится - уже интереснее.Во freebsd по соображениям "свободы" запрещено современную продукцию юзать.
> Во freebsd по соображениям "свободы" запрещено современную продукцию юзать.При том свободы всяких тивоизаторов тивоизировать. Ну вот пусть эти тивоизаторы и мучаются. Эти с...и, определенно, заслуживают такой участи.
>хуже поддержка c++11С этого места поподробнее.
Тот аноним намекает, что как бэ со стандартами у новины не всё ОК
Интересует список фич C++11, которые уже поддерживает gcc, но не поддерживает clang.
Сами вы ни за что не догадаетесь, поэтому подскажу первый шаг к такому списку: Википедия.
Судя по списку, Clang актуальной версии отстает только по двум пунктам.
Компилирует он как раз быстрее, а программы после этого таки да, работают медленнее.
> В сухом остатке Clang медленнее компилирует, программы собранные им медленнее работают, хуже поддержка c++11, LLVM поддерживает меньше языков...
> А столько пафоса было, столько пафоса.Зато - свобода от грязных лап опенсорца.
> Зато - свобода от грязных лап опенсорца.Зато можно тивоизировать. Что впрочем столь же оптимистично как "можно приковаться к батарее, совершенно добровольно".
А где главное, где выводы? Что на этой неделе эффективнее собирать clang-ом, а что gcc?
Будем ждать 3.3
А ещё лучше 4.0, чтоб уж точно...
Можно и до 5-й версии подождать, не лень.
на макинтоше clang 4.2 уже давно и система им собрана 10.8
> на макинтоше clang 4.2 уже давно и система им собрана 10.8не заю как там оверклок скорость на GCC, а вот стабильность и нагрев проца в приложениях clang отбалансированы ровно
Сам Джобс приложил к этому руку?Не порите чушь!
> нагрев проца в приложениях clang отбалансированы ровноДа, сразу видно что маком пользуются четкий пацаны с раёну.
>стабильность и нагрев проца в приложениях clang отбалансированы ровнодругими словами — в комьюните шланга входят не только эппл с айзеном, но и производители кипятильников и чайников.
То то она тормознее стала
>на макинтоше clang 4.2 уже давно и система им собрана 10.8во как!
т.е. окрызок опять прокинул бсдишнегов с их 3.1
> во как!
> т.е. окрызок опять прокинул бсдишнегов с их 3.1Вообще-то, огрызок и разрабтыват шланг. А бсд-шники прыгают перед ним на задних лапках и выпрашивают подачки.
Надо бы им и перед ораклом попрыгать, вдруг расщедрится и шифрование для ZFS подбросит.
> А где главное, где выводы? Что на этой неделе эффективнее собирать clang-ом, а что gcc?Ну, блин, клацни ссылку да посмотри. Шлангом эффективнее собирать несколько тестов SciMark. GCCом - все остальное. Хотя есть еще гибрид ужа с ежом, aka GCC с бэкэндом LLVM. Странной хрени - странные свойства, ибо местами оно всех рвет, но местами откровенно эпикфэйлит, по поводу чего обладает свойствами игры в рулетку.
>В большинстве тестов победил GCC, при том в некоторых тестах отличия достигали нескольких разПолностью совпадает с моим опытом.
Если Clang будет поддерживать столько же платформ и стандартов сколько GCC, то это будет New GCC. Не стоит гордиться легковесностью, когда речь идёт о существенно сокращённом функционале.
>Если Clang будет поддерживать столько же платформ и стандартов сколько GCC, то это будет New GCC.Нет, не будет. Clang/llvm более свежие. И по коду и по архитектуре. Только за счет того что код ИЗНАЧАЛЬНО заточен под расширяемость и не успел обрости костылями и legacy это уже не будет gcc. Плюс написано оно на С++.
> Нет, не будет. Clang/llvm более свежие. И по коду и по архитектуре.Свежесть кода меняется с каждым релизом.
А архитектура - вообще вопрос сложный. Можно в XXI веке наархитектурить гогно, которое работает хуже, чем софт с архитектурой из прошлого века (см. сабжевую новость).> Только за счет того что код ИЗНАЧАЛЬНО заточен под расширяемость и
У gcc тоже.
> не успел обрости костылями и legacyКогда допилят до юзабельного состояния - обрастет, куда ж без этого.
> Плюс написано оно на С++.
Вы так говорите, как будто это что-то хорошее.
> Если Clang будет поддерживать столько же платформ и стандартов сколько GCC,...а если коммунизм победит во всем мире... Ну в общем, когда победит - тогда и поверим в возможность этого.
пофиг, пока буду сидеть на GCC либо перейду на GCC бэкэнд к LLVM - пофигу, для меня GCC так и останется GCC
да все верно. из плюсов clang хорошие сообщения об ошибках и поиск ошибок в исходниках с помощью clang-checker - что уже здорово.
>из плюсов clang хорошие сообщения об ошибкахGCC 4.8 уже подтянулся, советую посмотреть.
Спасибо Clang, что растолкали gcc-шников на новые фичи.
Фичи у гцц всегда добавлялись не по мелочи (и сабж подтверждает).
А вот стразики — это да.
>>из плюсов clang хорошие сообщения об ошибках
> GCC 4.8 уже подтянулся, советую посмотреть.ага. к счастью, этот маразм можно отключить. надеюсь, в configure будет опция, чтобы оно исчезло и больше никогда не появлялось. потому что одни идиоты попутали терминал и картины Малевича, а другие наслушались идиотов и решили делать то же самое, но пока хоть без цвета. как будто редакторы разучились переходить по номеру строки и позиции в оной, а терминалы стали бесконечно видимой высоты.
дайте угадаю, они на gcc & clang компелировали обои и оценивали результаты
подскажите когда в gcc будет доступен бесплатный статический анализатор - как в clang?
А зачем? У меня http://clang-analyzer.llvm.org/scan-build.html прекрасно работает и с GCC.
От виндотроллей заказы не берём.
> подскажите когда в gcc будет доступен бесплатный статический анализатор - как в clang?Кэп намекает что бесплатных статических анализаторов в мире есть и без clang.
> подскажите когда в gcc будет доступен бесплатный статический анализатор - как в clang?Уже давно.
с помощью gcc можно скомпилить clang... и наоборот? мне эти результаты интересны
С помощью gcc можно скомпилировать clang - я проверял. Правда после этого рекомендуют собранным clang собрать clang еще раз для верности и оптимальности кода. Наоборот - не пробовал.
> с помощью gcc можно скомпилить clang... и наоборот? мне эти результаты интересныИ так, и эдак можно.
А разве в коде gcc не используются gcc-специфичные фишки?
Странно, что они никак не примут lldb в мэйнстрим. Как же они отлаживают?
> Странно, что они никак не примут lldb в мэйнстрим. Как же они отлаживают?Кстати да, будет интересно: а фрибсдшники теперь
- Не будут дебажиться?
- Засунут гордость туда где ей самое место и поюзают современный gdb?
- Напишут свое, с бородатыми мужиками и тумблерами на шинах?
- Будут юзать неотдебаженый дебагер от эппла?
- Или что-нибудь еще что я забыл...
>Кстати да, будет интересно: а фрибсдшники теперь
>- Не будут дебажиться?Будут.
>- Засунут гордость туда где ей самое место и поюзают современный gdb?
Нет, будут использовать старый запатченный gdb 6.x
>- Напишут свое, с бородатыми мужиками и тумблерами на шинах?
Нет. См. выше.
>- Будут юзать неотдебаженый дебагер от эппла?
Нет. См. выше. До тех пор пока эпл его не отдебажит.
> Нет, будут использовать старый запатченный gdb 6.xА не могли бы вы поподробнее про это? Может быть даже со ссылкой куда-то?
Я видел последние обсуждения отладчика в списках рассылки очень давно, поэтому ссылок не найду. В системе сейчас GDB 6.1.1, пока его выпиливать никто не собирается (в ближайшее время). Как альтернатива рассматривается lldb, но вот уже больше года его статус на вики так и застрял на 75%. Но тут опять же больше речь идёт об отладчике ядра. Юзерспейс никто не запрещает отлаживать новыми версиями GDB.И Clang с GDB никак не противоречат друг другу, поэтому ничего не мешает использовать их вместе.
> Я видел последние обсуждения отладчика в списках рассылки очень давно, поэтому ссылок
> не найду. В системе сейчас GDB 6.1.1, пока его выпиливать никто
> не собирается (в ближайшее время).///---
% man gdb
GDB(4) FreeBSD Kernel Interfaces Manual GDB(4)NAME
gdb — external kernel debuggerSYNOPSIS
makeoptions DEBUG=-g
options DDBDESCRIPTION
The gdb kernel debugger is a variation of gdb(1) which understands some
aspects of the FreeBSD kernel environment. It can be used in a number of
ways:· It can be used to examine the memory of the processor on which it
runs.· It can be used to analyse a processor dump after a panic.
· It can be used to debug another system interactively via a serial or
firewire link. In this mode, the processor can be stopped and single
stepped.· With a firewire link, it can be used to examine the memory of a
remote system without the participation of that system. In this
mode, the processor cannot be stopped and single stepped, but it can
be of use when the remote system has crashed and is no longer
responding.When used for remote debugging, gdb requires the presence of the ddb(4)
kernel debugger. Commands exist to switch between gdb and ddb(4).
...
...
...
BUGS
The gdb(1) debugger was never designed to debug kernels, and it is not a
very good match. Many problems exist.The gdb implementation is very inefficient, and many operations are slow.
Serial debugging is even slower, and race conditions can make it diffi
cult to run the link at more than 9600 bps. Firewire connections do not
have this problem.The debugging macros “just grown”. In general, the person who wrote them
did so while looking for a specific problem, so they may not be general
enough, and they may behave badly when used in ways for which they were
not intended, even if those ways make sense.Many of these commands only work on the ia32 architecture.
FreeBSD 9.1 February 8, 2005 FreeBSD 9.1
---///> Как альтернатива рассматривается lldb, но вот
> уже больше года его статус на вики так и застрял на
> 75%. Но тут опять же больше речь идёт об отладчике ядра.
> Юзерспейс никто не запрещает отлаживать новыми версиями GDB.
> И Clang с GDB никак не противоречат друг другу, поэтому ничего не
> мешает использовать их вместе.К тому же, на продакшене отладка не нужна. GDB исключается из системы опцией WITHOUT_GDB=true в /etc/src.conf и убиранием строчки "makeoptions DEBUG=-g" в файле конфигурации ядра с последующей пересборкой ядра и системы.
> К тому же, на продакшене отладка не нужна.Кроме того случая когда не повезло и что-то все-таки факапнулось. И некисло бы понять что и где. Конечно, можно взять шаманский бубен и попробовать прогнать злых духов из процессора. Но эффективность этого способа оспаривается многими администраторами и программистами.
>> К тому же, на продакшене отладка не нужна.
> Кроме того случая когда не повезло и что-то все-таки факапнулось. И некисло
> бы понять что и где. Конечно, можно взять шаманский бубен и
> попробовать прогнать злых духов из процессора. Но эффективность этого способа оспаривается многими администраторами и программистами.А я, вообще, в последнее н-дцать лет как-то научился отделять администраторские функции ("паковка") от программистских способностей ("картостроение"). И вам того желаю. Помогает, знаете ли, в жизни — http://progstone.narod.ru/reciprocality/r0/index.html
Спасибо, чему ты научился я видел. Быть таким же унылым овощем который ни в чем не шарит я не желаю, извини.
> Спасибо, чему ты научился я видел.И чему же?
> Быть таким же унылым овощем который ни в чем не шарит я не желаю, извини.
А придётся поначалу. ;)
Пока же подтяни русский язык, а там посмотрим на то, что ты умеешь, и прочтём то, о чём ты пишешь. :)
> И чему же?1) Ламерить.
2) Ввязываться в дискуссии в которых тебе не позволяет участвовать квалификация.
3) Носиться с сомнительной хренью истошно засирая форум ее рекламой и игнорируя ее недостатки.
4) Получать 6Mb/sec на шпиндель. 'Coz it's just EPIC.>> Быть таким же унылым овощем который ни в чем не шарит я не желаю, извини.
> А придётся поначалу. ;)Эта фаза прошла много лет назад.
> Пока же подтяни русский язык, а там посмотрим на то, что ты
> умеешь, и прочтём то, о чём ты пишешь. :)Ну да, будучи сонным пропустил пару запятых. Это не потому что я русский не знаю. Это потому что спать надо больше :P.
Ну привет, User294. Жги дальше со своими "6 МБ/с на шпиндель" и волшебными экстентами на Ext4. Другого тебе не остаётся. Верим, Btrfs в продакшене быть. Хорошо быть apt-getчиком. :))
> Ну привет, User294. Жги дальше со своими "6 МБ/с на шпиндель"Так это твой отжиг, если что :)
>> Ну привет, User294. Жги дальше со своими "6 МБ/с на шпиндель"
> Так это твой отжиг, если что :)Это отжиг User294, вырванный из контекста. Теперь бегает со своими "6 МБ/с на шпиндель" и тут в каждой теме о FreeBSD/ZFS/Clang радостно докладывает о своём "открытии". :))
Linux с падучей Ext4 и недоделанной Btrfs у него верх совершенства и функциональности: "А вот они-то себе подобного не позволяют!". :)) Да, они много чего себе не позволяют, потому что у них этого "много" ещё нет и быть в ближайшие несколько лет не может. :))
> А я, вообще, в последнее н-дцать лет как-то научилсяи вот всё у тебя «как-то». лучше бы ты полы подметать научился, но зато хорошо, а не «как-то». всяко пользы больше было бы — и тебе, и окружающим.
ну как бы ktrace никто не отменял. не замена, но подспорье.
> ну как бы ktrace никто не отменял. не замена, но подспорье.Ну как бы трассировщик и дебаггер - "немного" разные штуки.
> В системе сейчас GDB 6.1.1, пока его выпиливать никто не собираетсяА в чем проблема использовать последние версии gdb?
> И Clang с GDB никак не противоречат друг другу, поэтому ничего не мешает использовать их вместе.
А вот это я пробовал. В общем-то работает, но гораздо хуже, чем gcc+gdb. Самое неприятное из того, что встретилось мне - проблемы с чтением RTTI для определения реальных типов данных и их полноценного отображения (а для C++ разработки это критично, имхо). Иногда также были странные фокусы с пошаговой отладкой (естественно, оптимизация была отключена).
Хотя это было для clang 3.1 и соответствующего ему lldb. Когда выйдет 3.2 - попробую его еще. По сравнению с 3.0, 3.1 стал гораздо стабильнее.
> А в чем проблема использовать последние версии gdb?Например, религиозная ненависть к гпл3 :)
религиозная ненависть к фанатикам - которые статически линкуя код libgcc - навязывают любой собранной программе GPL v3. для вас это сюрприз что скопилировав при помоши gcc любой код и выложив его на публику ты обязан выполнять требования GPL v3 и с твоим мнением на счет выбора лицензии никто не считается?
> религиозная ненависть к фанатикам - которые статически линкуя код libgcc - навязывают
> любой собранной программе GPL v3.GCC Runtime Library Exception уже _давно_ https://www.opennet.ru/openforum/vsluhforumID3/52871.html#22 исправлен.
> для вас это сюрприз что скопилировав
> при помоши gcc любой код и выложив его на публику тыВраньё.
> обязан выполнять требования GPL v3 и с твоим мнением на счет
> выбора лицензии никто не считается?Хорошо, что FrerBSD Core Team сделала выбор. Плохо, что _её_ рьяные фанатики не понимают причины и несут полную отсебятину. Методички что ли выпускали бы...
> GCC Runtime Library Exception уже _давно_ https://www.opennet.ru/openforum/vsluhforumID3/52871.html#22
> исправлен.оно не знает, ему прошивку не обновили.
> религиозная ненависть к фанатикам - которые статически линкуя код libgcc - навязывают
> любой собранной программе GPL v3.И кстати, _они_ не "линкуя". "Линкуя" -- ты. И "линкуя", ты ж обязан исполнить и лицензию, и её exceptions.
Та-что да, елси _ты, "линкуя", навязываешь GPLv3, [по сю пору то есть,] то ты - фанатик и неуч.
> Нет, будут использовать старый запатченный gdb 6.x
> Нет. См. выше. До тех пор пока эпл его не отдебажит.Ну я как-то так и подозревал...
> Как же они отлаживают?Дебажный printf же самый позиксвейный и юникслайковый отладочный кундштюк.
Вы не понимаете!
> Дебажный printf же самый позиксвейный и юникслайковый отладочный кундштюк.На самом деле это клевый метод дебага, но проблема в том что программа должна быть уже написана с оным. И кроме того для многопоточных или event-driven программ это может быть не совсем удобно.
> И кроме того для отоладки программ это может быть не совсем удобно.Fixed.
>> И кроме того для отоладки программ это может быть не совсем удобно.Фикс заглючен :)
Да, его самого не мешало бы отладить
>> Как же они отлаживают?
> Дебажный printf же самый позиксвейный и юникслайковый отладочный кундштюк.
> Вы не понимаете!отличная штука, кстати. как ты думаешь, почему логи до сих пор живее всех живых, и сдавать позиции не собираются?
впрочем, «интерактивные отладчики» незаменимы для офисных долбокодеров: потому что щёлкаешь ерундой в отладчике — вроде и работаешь. и, главное, думать при этом не надо. то ли дело воооон тот бездельник, который курит и в карманный комп пырится: явно же смИшные картинки смотрит! а то, что за ним куча багфиксов, а за Активным Работником только багодельня — так это потому, что Активный Работник активно работает, некогда ему всякой ерундой типа багфиксов заниматься.
такие дела.
А может же такое случиться, что появятся две версии ну на пример Ubuntu 13.04 собранные разными компиляторами? и собсно говоря можно было бы тогда более предметно говорить что есть что, и какой результат. Ведь это же не сложно в мэйк файле подставить компилятор.
Ubuntu clang не собирает. Он ядро то собирает после хаков.
> А может же такое случиться, что появятся две версии ну на пример
> Ubuntu 13.04 собранные разными компиляторами?Много геморроя неизвестно ради чего.
Clang очень быстро собирает приложения, а GCC — слоупок в полтора-два раза.На десктопе скорость выполнения интерактивных приложений не сильно важна.
Выключите оптимизацию в GCC, будут те же результаты, что и у Clang> На десктопе скорость выполнения интерактивных приложений не сильно важна.
Кому как. Лично мне заметна даже небольшая задержка при открытии приложения, и это раздражает
>Clang очень быстро собирает приложения, а GCC — слоупок в полтора-два раза.
>На десктопе скорость выполнения интерактивных приложений не сильно важна.да-да!!!
на десктопе гораздо важнее как быстро собирает, а не как выполняет. :Dвот так берёшь 4-ядерный проц и (минимум) одно ядро даришь.
не, гпл-хэйтеры (аля айзен) и 3-и ядра отпилят, лишь бы хоть одно выполняло только кошерно-собранный код, это-то понятно.
а вот остальным это зачем, не понятно.
> на десктопе гораздо важнее как быстро собирает, а не как выполняет. :DНу фрибсдшнику важнее ясен пень. Он же поди все из сорцов собирает. Что веселее всего - он поди в севом сорце вообще ничерта поменять не способен. Ибо жабист унылый.
>> на десктопе гораздо важнее как быстро собирает, а не как выполняет. :D
> Ну фрибсдшнику важнее ясен пень. Он же поди все из сорцов собирает.Почему "поди"? Всё! Но тебе этого не дано. Ты — убунтолог и привык к тому, что за тебя кто-то соберёт и запакует нужный тебе блоб. А ты и рад до смерти — своего-то навыка "канпеляции" нет. :))
> Что веселее всего - он поди в севом сорце вообще ничерта поменять не способен.А чего менять-та, если всё собирается и работает?
> Ибо жабист унылый.
Да ты со своей убунточкой унылей кажешься.
Такой вопрос: какие весомые преимущества дает тотальная сборка из исходников? Причем не отдельных программ, которые требуется собрать со своими патчами/опциями компиляции, а почти всей системы?
> Такой вопрос: какие весомые преимущества дает тотальная сборка из исходников?
> Причем не
> отдельных программ, которые требуется собрать со своими патчами/опциями компиляции, а
> почти всей системы?+ Нет постороннего "мусора", который нужно ещё сопровождать — есть чётко определённая конфигурация зависимостей.
+ Компактность и понятность сборки.
+ Оперативные обновления и патчи.
+ Существенная экономия времени: нужно скачать только исходники, а с чужими блобами разбираться не нужно.
> + Нет постороннего "мусора", который нужно ещё сопровождать — есть чётко определённая конфигурация зависимостей.Рядовые апт-гетчики ничего не сопровождают
> + Компактность и понятность сборки.
Не очень понял про компактность. Процесс сборки более понятен, чем процесс распаковки пакета?
> + Оперативные обновления и патчи.
Пожалуй, реальное преимущество. Хотя в дебиане фиксы безопасности тоже прилетают оперативно, а сборка на ихнем сервере почти наверняка быстрее, чем у себя дома.
> + Существенная экономия времени: нужно скачать только исходники, а с чужими блобами разбираться не нужно.
Экономия времени по сравнению с чем? Из исходников сборка происходит быстрее, чем распаковка бинарного пакета?
> а с чужими блобами разбираться не нужно
В каком смысле "чужие", и чего с ними "разбираться"? В пакетных линуксах исходники точно так же доступны, если надо, и из них можно собрать абсолютно такой же пакет, что и в репозитории, с точностью до байта, и убедиться, что одно получено из другого
>>> на десктопе гораздо важнее как быстро собирает, а не как выполняет. :D
>> Ну фрибсдшнику важнее ясен пень. Он же поди все из сорцов собирает.
> Почему "поди"? Всё! Но тебе этого не дано. Ты — убунтолог и
> привык к тому, что за тебя кто-то соберёт и запакует нужный
> тебе блоб. А ты и рад до смерти — своего-то навыка
> "канпеляции" нет. :))
>> Что веселее всего - он поди в севом сорце вообще ничерта поменять не способен.
> А чего менять-та, если всё собирается и работает?
>> Ибо жабист унылый.
> Да ты со своей убунточкой унылей кажешься.А попробуй RHEL из SRPMS пересобрать.Там всякими without_* with_* в make.conf,src.conf
не обойдёшься.И автоматизацию сборки самому придётся велосипедить.Так что аптгет...
простите,маккинстальщики,это скорее вы,бздисты.И,вообще,серьёзен только бздист,
знающий наизусть хотя бы процентов пять исходного кода,например,ядра.Все остальные
просто сранноваты в своей гордости по поводу того,что набирают не apt-get *,а make *.
> Почему "поди"? Всё! Но тебе этого не дано. Ты — убунтолог и
> привык к тому, что за тебя кто-то соберёт и запакует нужный тебе блоб.А зачем мне прошибать вообще все стены моим лбом? Лоб не казенный - пересобирать и паковать лично я буду то что было мной модифицировано. А просто повторить чью-то еще работу - а нафига? Я ленивый :)
> А ты и рад до смерти — своего-то навыка "канпеляции" нет. :))
Я вполне в состоянии собрать транк-версию нужных мне программ, кастомное ядро или что там еще. Если это становится надо. Приколись, да? Я даже могу исправить ошибки если транковая версия не компилится. На чем ты IMHO зафэйлишь.
>> Что веселее всего - он поди в севом сорце вообще ничерта поменять не способен.
> А чего менять-та, если всё собирается и работает?"А нафига самому билдовать, если все и так работает?" :)
>> Ибо жабист унылый.
> Да ты со своей убунточкой унылей кажешься.ЧСВ такое ЧСВ, при том проблема в том что скиллами не подкреплено. Заметь, я сисколлы своей системы получше тебя знаю :)
> Clang очень быстро собирает приложения, а GCC — слоупок в полтора-два раза.
> На десктопе скорость выполнения интерактивных приложений не сильно важна.изя, ты как всегда фееричен. я даже не буду спрашивать тебя, слышал ли ты что-то про «комфортную скорость реакции софта». и про то, что современная называется «атомно тормозит» — просто такие как ты привыкли уже питаться гуано, и уверены, что без нормы не прожить.
http://lists.freebsd.org/pipermail/freebsd-current/2012-Nove...- Kernels compiled with clang 3.2 at -O2 are ~8% faster in system time
than kernels compiled with gcc 4.2.1 at -O2.
- Kernels compiled with clang 3.2 at -O2 perform equally to kernels
compiled with gcc 4.7 at -O2, there is no significant difference.
- Kernels compiled with gcc 4.7 at -O3 have a slight advantage in system
time (~3.6%) against kernels compiled with clang 3.2 at -O2.
(I did not test a kernel compiled with clang 3.2 at -O3.)
Во, истинные бсдшники. Забенчить только кернель фиг знает как. Все, решение есть - можно идти спать :) //анекдот про математика и пожарный кран
Это при том, что в портах фри есть http://www.freshports.org/lang/gcc48/
> (I did not test a kernel compiled with clang 3.2 at -O3.)вот это правильно. И это как бы намекает, что по стабильности шланг 3.2 как на уровне того самого gcc-4.8, с которым его и следовало сравнивать. Но почему-то не стали.
Уже или clang-3.2 vs gcc-4.7 или clang-3.2 vs gcc-4.8
> Уже или clang-3.2 vs gcc-4.7 или clang-3.2 vs gcc-4.8
> Уже или clang-3.1 vs gcc-4.7 или clang-3.2 vs gcc-4.8fix
> Уже или clang-3.2 vs gcc-4.7 или clang-3.2 vs gcc-4.8А по ссылке сходить? Религия не позволяет?
Английским по белому написано, что ядро собранное gcc-4.8 не взлетело. Как его тестировать?
Лень. Но и смысла нет в этом тесте, ведь ядро фри пилится с прицелом именно на шланг, удивительно, что оно 4.7 собралось.
> ведь ядро фри пилится с прицелом именно на шланг, удивительно, что оно 4.7 собралось.Ага, аж с целого пятого ноября!
> Но и смысла нет в этом тестеСмысл в этом тесте как раз и есть. Пересборка мира, особенно многопоточная, затрагивает работу практически всего ядра, т.е. шедулера, VM, IPC, IO и т.д. Поэтому она является хорошим показателем пригодности subj-а к сборке конкретного ядра конкретной системы.
> удивительно, что оно 4.7 собралось.
А что ему должно мешать? 4.2 собирает, а более последующие верии gcc не отмечены особенным наплевательством на стандарты. Фревый вариант gcc, правда, содержит поддержку некоторых нестандартных расширений, но правильным заданием опций сборки это можно нейтрализовать.
> Уже или clang-3.2 vs gcc-4.7 или clang-3.2 vs gcc-4.8Попробуйте прочитать новость. Все там сравнили - и шлинг 3.1 и SVN версию 3.2 которая еще не релизнулась. И гцц как 4.7, так и 4.8 еще не выпушенный.
Большой облом для вас состоит в том что если вкратце то clang 3.2 почти не отличается от 3.1 а гцц 4.8 мало отличается от 4.7. Различие между семействами компилеров много сильнее чем между соседними версиями внутри семейств.
угу.
особенно интересна методика сравнения:
>With that kernel booted, I timed how long a "make -j8 buildworld" took, compared to booting with kernels compiled by gcc in base (v4.2.1) and clang in base (v3.2), on different optimization settings.т.е. реалити-шоу «а под каким ядром шланг компилит быстрее?» :D
или гцц (если он buildworld им собирает). не говоря уже про версии.
что впрочем на рейтинги шоу не влияет, не так ли?
> т.е. реалити-шоу «а под каким ядром шланг компилит быстрее?» :DНе, кончено они тоже что-то забенчили, но после таких бенчей визги нагуалов относительно фороникса выглядят как-то неубедительно, имхо. В общем сферический вакуум засчитан.
> а гцц 4.8 мало отличается от 4.7.За исключением одной мелочи: gcc-4.8 компилится g++
>> а гцц 4.8 мало отличается от 4.7.
> За исключением одной мелочи: gcc-4.8 компилится g++Имелись в виду свойства генерации кода. В этом плане что LLVM 3.1 vs 3.2, что GCC 4.7 vs 4.8 показали что различия между версиями довольно небольшие. Каких-то крупных прорывов или наоборот сильных регрессий ни в одном тесте IIRC не зафиксировано.
Делетанты тестровщики - профайлинг не сделали, в каких местах проги тормозили
На кол их
> Делетанты тестровщики - профайлинг не сделали, в каких местах проги тормозили На кол ихНу мы ждем когда вы возьмете профайлер и это сделаете. Просим, просим.
> Делетанты тестровщики - профайлинг не сделали, в каких местах проги тормозили
> На кол ихфорониксы как бы тоже.
а вообще зря минусанули, профайлинг был бы не только интересен но и полезен.
> а вообще зря минусанули, профайлинг был бы не только интересен но и полезен.Плюсанем. Когда он научится писать без багов + возьмет в руки профайлер и отпрофайлит, собственно.
> Делетанты^^^^^^^ Дилетанты. По русскому языку.
> тестровщики
У ^^^^ нас хрен проскочишь.
> На кол их
Точку забыли. Однозначно на кол. Граммар-наци одобряют. И тестировщики, обнаружившие в элементарном посте на 2 строчки целых 3 (!!!) бага.
http://llvm.org/docs/index.html
Тестирование финальной версии LLVM/Clang 3.2, предыдущей версии LLVM/Clang 3.1, стабильного релиза GCC 4.7.2 и снапшота разрабатываемого GCC 4.8 по состоянию на 23 декабря 2012г:
http://www.phoronix.com/scan.php?page=article&item=llvm_clan...