Опубликованы (http://www.phoronix.com/scan.php?page=article&item=apple_llv...) результаты сравнения производительности компиляторов GCC и LLVM-GCC.GCC оказался немного быстрее в 5 тестах (LAME MP3, dcraw, Dhrystone 2, Crafty chess, Tachyon ray-tracing), а LLVM-GCC в 2 (MAFFT, C-Ray). Значительное преимущество GCC продемонстрировал в тесте John The Ripper, обогнав LLVM-GCC на 40%, но LVM-GCC опередил GCC на 30% в тесте OpenSSL.
URL: http://www.phoronix.com/scan.php?page=article&item=apple_llv...
Новость: http://www.opennet.me/opennews/art.shtml?num=23297
Угу, я тоже их мерял, также +/- 1.5 раза. Что меня поражает - какой-то LLVM о котором год назад и слыхом не слыхивали и которой реально даже нигде в мэйнстриме не используется, уже показывает сравнимые с gcc (которому уже больше 20 лет!) результаты. Будущее однозначно за ним. Не все но уже некоторые (FreeBSD) это понимают.
Об LLVM год назад не слышали? Да на него ж Apple ставит и поддерживает уже давным давно.
компания apple всегда отличалась высоким качеством продукции
>компания apple всегда отличалась высоким качеством продукциипримеры встудию
iPod, AppleTV, iMac, WebKit, LLVM, Quartz
Что ж iPhone не упонямули и MacOSX? И не мешайте все в одну кучу - все что закрытое у них - редкосное дерьмецо. А открытое неплохое. И думается, Apple тут совсем не при чем, просто так мир устроен :)
>Что ж iPhone не упонямули и MacOSX?они в этом не нуждаются.
>И не мешайте все в одну кучу
речь об одной компании
>все что закрытое у них - редкосное дерьмецо
ну да, ну да, вроде iTunes, который безуспешно пытаются скопировать все остальные плееры. наиболее близко - если оценивать интерфейс - подобрался Songbird.
>просто так мир устроен
да, от троллей сложно избавиться. они как термиты
>да, от троллей сложно избавиться. они как термитыА анонимы вообще как тараканы - тоже вывести трудно и в массе своей весьма противные.
> они в этом не нуждаются.Мне почему-то больше кажется что просто стыдно.
>> все что закрытое у них - редкосное дерьмецо
> ну да, ну да, вроде iTunesВо-во, читаете мои мысли.
> который безуспешно пытаются скопировать все остальные плееры
Ага, только как ни пытаются, такое же махровое недоразумение никак не выходит
я бы даже ответил на реплику, только здесь трут неугодные комментарии. поэтому нахер надо
а Вы попробуйте аргументированно, без оскорблений...
>я бы даже ответил на реплику, только здесь трут неугодные комментарии. поэтому
>нахер надоЗнаете, как человек сообщения которого модераторы стирают (и не то чтобы редко), хочу заметить что в большинстве случаев у них все-таки на это есть какие-то причины, при том эти причины обычно все-таки не самодурство.Гораздо чаще причиной сноса выступает какая-нибудь площадная брань в три этажа но зато без аргументации.Так туда и дорога таким постингам :P.Это так, немного наблюдений за тем что было убито в последнее время.
Мне кажется что если б вы культурно и обоснованно выложили вашу точку зрения - никто бы ее стирать не стал.
>iPod,Интерфейс у него для придурков, которые ради понта готовы на все, даже обучиться этому интерфейсу. ИМХО.
> WebKit,
А тут все просто - это не Эппл сделал а КДЕшники. А то что эппл немного доработал - авторами кода их не делает. Если б эппл делал это сам с нуля - был бы закрытый блоб типа quartz-а.
> Quartz
В качестве оного мы все уже убедились. Читая бюллетени уязвимостей, разумеется. Где этот "качественный продукт" является частым гостем, не сказать бы завсегдатаем.
> Об LLVM год назад не слышали? Да на него ж Apple ставит и поддерживает уже давным давно
> компания apple всегда отличалась высоким качеством продукцииСарказм разделяю - вот что-то, а от Apple такого не ожидалось. В данном случае, как ни странно, они сотворили не себе-на уме костыль типа Objective-C и не вселенский ужас как любая их продукция.
Слышишь звон, да не знаешь откуда он.Обьясни своими словами чего плохого в Objective-C, думаю у тебя должен быть опыт написания софта на нём раз говоришь так.
>Угу, я тоже их мерял, также +/- 1.5 раза. Что меня поражает
>- какой-то LLVM о котором год назад и слыхом не слыхивали
>и которой реально даже нигде в мэйнстриме не используется, уже показывает
>сравнимые с gcc (которому уже больше 20 лет!) результаты.А что это доказывает? Если кто не понял - производительность стремится к идеалу не линейно а скорее, асимптотически.Потому что предельная производительность - не бесконечность а всего лишь производительность CPU при идеально оптимизированной последовательности команд :). Это, очевидно, один из тех случаев когда за 2 года можно получить 80% результата и еще 10 лет убить на остальные 20% :).Потому что чем ближе к идеальной производительности тем труднее что-от отыграть.
Мерилась скорость самого компилятора или скорость скомпилированных бинарников?
>>LAME MP3, dcraw, Dhrystone 2, Crafty chess, Tachyon ray-tracing
>Мерилась скорость самого компилятора или скорость скомпилированных бинарников?Не уж то из новости непонятно?
да, сформулировано криво (и в заголовке оригинала тоже), но если всё-таки прочитать оригинал, то увидим:
With the resulting binaries from GCC and LLVM-GCC, we then looked at their performance.
Интересно будет сравнить LLVM-GCC и LLVM-Clang, у кого уже Snow Leopard - попробуйте
>Интересно будет сравнить LLVM-GCC и LLVM-Clang, у кого уже Snow Leopard -
>попробуйте
не забывайте что gcc кросплатформенный во всех отношениях. сравнивать микрософтовские поделки не уместно вообще
Кроссплатформенность ни о чём не говорит, программистам нужны компиляторы под конкретные платформы, и качество. То, что gcc работает везде понемногу, не значит, что в конкреных случаях он лучше. На Sparc лучше всех Sun Studio, не нужно объяснять почему? на Intel - Intel, и MS; gcc лучше там, где ничего нет
Все намного проще - gcc лучше, потому что есть везде. Никому нафиг не нужно под каждую платформу использовать отделный велосипед, а то что он лучше на два процента на каких-то там задачах в вакууме, погоды не делает. Так что intel, sun и ms - удел тех, кто пишет недософт под одну платформу.
>два процента на каких-то там задачахнолик припиши
0,2 % так чтоли?
Кроссплатформенность это хорошо, но если она не в ущерб качеству, а это бывает редко. Обычно люди пытаются заменить технологию политикой и получается кроссплатформенность ради кроссплатформенности, свобода ради свободы ... Системы слишком отличаются по назначению, чтобы быть одинаковыми, и если вы не используете системозависимые API - вы лишаете себя очень многого и теряете производительность. Никто не пишет серьёзные программы "под все системы" обычно выбирают две - три.
>Кроссплатформенность это хорошо, но если она не в ущерб качеству, а это бывает редко. Обычно люди пытаются заменить технологию политикой и получается кроссплатформенность ради кроссплатформенности, свобода ради свободы ... Системы слишком отличаются по назначению, чтобы быть одинаковыми, и если вы не используете системозависимые API - вы лишаете себя очень многого и теряете производительность. Никто не пишет серьёзные программы "под все системы" обычно выбирают две - три.Вы программист? Выбирают совсем не поэтому. и никогда не выбирали по этому критерию.
даже не представляете - языки с/с++/... на всех (нет. не так. вот так - НА ВСЕХ) платформах одинаковые (что гарантируется их стандартами). впрочем, почти все другие языки - тоже. что же до апи - так они просто не вызовутся на не целевой платформе (насколько всё-таки бзд ближе всех к линуху, а и то линуксулятор нужен). приходиться в исходниках дублировать код для разных платформ и при компиляции берётся тот или иной кусок кода.
говоря об системозависимых API Вы видимо имели ввиду различные библиотеки/библиотеки классов... здесь скорость зависит только лишь от качества кода библы под конкретную платформу и... самой платформы.
Программист. Я имею в виду не языки, а API, зачем, например использовать Qt на Mac, если там есть свои либы, гораздо более удобные и интегрированные с системой? Что касается дублирования кода для разных платформ эти #ifdef / #endif - раздувают код и их тяжело читать, самый лучший способ вынести то, что на чистом языке отдельные либы, и разные проекты для разных систем.
а зачем на винде тогда использовать mfc, atl, vcl,... .net наконец? юзать апи виндов напрямую и вся недолга.
ан нет, проги, использующие только апи виндов, уже днём с огнём не найти.
>Mac, если там есть свои либы, гораздо более удобные и интегрированные с системой?ой ли? по мне, так тотже Qt НАМНОГО удобней... особенно если на С/С++ проект, а не обджси.
а если на java? на пёрле? не использовать их библиотеки/модули?
>Что касается дублирования кода для разных платформ эти #ifdef / #endif - раздувают код и их тяжело читать, самый лучший способ вынести то, что на чистом языке отдельные либы, и разные проекты для разных систем.только исходный код, на качестве и размере скомпилированного блоба это не отражается.
а читать не удобно, ну.. извините, но не знаю как и сказать то по-культурней... а Вам не интересно как это на другой платформе реализуется? или вынести в другие h-файлы, классы и т.д. не судьба?
ну а если Вас интересует только одна платформа, только один язык и только одна библиотека классов (всё для той же одной платформы), то это не повод хаять все остальные.
>проги, использующие только апи виндов, уже днём с огнём не найтида лааадно... та же миранда, к примеру - только системные либы (kernel*, user*, gdi*, msvcrt, wsock и т.п.)
>а читать не удобно, ну.. извините
от директив условной компиляции планировали со временем отказаться
исходники кагбэ предназначены для чтения и редактирования человеком>>Mac, если там есть свои либы, гораздо более удобные и интегрированные с системой?
>
>ой ли? по мне, так тотже Qt НАМНОГО удобнейкое-кто невнимательно читает
"интегрированные с системой"
>да лааадно... та же миранда, к примеру - только системные либы (kernel*, user*, gdi*, msvcrt, wsock и т.п.)видимо именно поэтому миранда заменила офисы, браузеры, редакторы графики,....
с таким аргументов - к блондинкам... на другом этаже.
>от директив условной компиляции планировали со временем отказаться
>исходники кагбэ предназначены для чтения и редактирования человекомкто планировал то?
xml - тоже планировали для удобства чтения человеком... результат - окунная радость в vi конфигурашки правть
>кое-кто невнимательно читает "интегрированные с системой"кое-кто не понимает - а зачем? шоб было?
и что значит - "интегрированные с системой"? вбит молотком в ЦПУ?
моя прога на Qt - не менее интегрирована с системой, чем все остальные....
а изменения в апи (того же мака. часто страдают этим) - тот ещё подарок одного вендора.
Qt и вообще С++ ужас сплошной, но это фломастеры, что касается Cocoa - гибче и удобней не нашёл, может искать не умею? посоветуйте!
>Программист. Я имею в виду не языки, а API, зачем, например использовать Qt на Mac,Затем что писать ТОЛЬКО под мак - не очень прикольно, а? А потом отдельно писать под виндовс? Под линукс? И под еще чего-нибудь? Ну вот вам и флаг в руки сделать 1 и ту же работу 3-4-эн раз подряд, если оно вам надо.
>>Программист. Я имею в виду не языки, а API, зачем, например использовать Qt на Mac,
>
>Затем что писать ТОЛЬКО под мак - не очень прикольно, а? А
>потом отдельно писать под виндовс? Под линукс? И под еще чего-нибудь?
>Ну вот вам и флаг в руки сделать 1 и ту
>же работу 3-4-эн раз подряд, если оно вам надо.There is of the matter is that я пишу на ObjC на mac, а код специфичный для Win и Linux - проблема моих коллег (или аутсорсеров). Я считаю, что невозможно знать всё, и лучше выбрать одну систему и изучить её.
>самый лучший способ вынести то, что на чистом языке отдельные либы,
>и разные проекты для разных систем.А разве либы по типу Qt именно этим не занимаются? oO
Да, и про качество не надо - я достаточно плотно работал с icc чтобы понять какой это лютый п--ц.
>gcc лучше там, где ничего нетэто типа линухи, бзди, ораклы, эйбиэмы.... т.е. операционки (кроме мс), субд (кроме мс), веб-сервера (кроме мс).... я ничего не забыл? :-D
интересно, через какую ОС провайдера Вы этот бред написали?ps:
>россплатформенность ни о чём не говорит, программистам нужны компиляторы под конкретные платформы, и качество.программистам нужны не компиляторы, а такие ИДЕ, чтобы работать поменьше, а получать по-больше. и именно этим объясняется популярность делфей и сппбилдера (а компилятор там был один из самых тормозных, но не хуже всех поддерживал стандарты... кстати, кто худший по последнему критерию догадываетесь? :-D)
>компилятор там был один из самых тормозныхгде, в делфях?
говорим вроде о си/си++ (ну да там без разницы).
да. си++ билдер (4.xx, 5.xx, 6.xx) генерил более медленный блоб, чем vc, icc и даже gcc.
>Кроссплатформенность ни о чём не говорит, программистам нужны компиляторы под конкретные платформы,А gcc удобен как раз тем что есть под разные платформы. Освоить 1 комплект компилеров и смочь генерить код для совершенно разных систем - от системы-на-чипе, таракана размером менее почтовой марки до могучих суперкомпьютеров - это вам не хухры-мухры.Хотя понтовым фанбоям с их супер-дупер IDE заменяющего мозг разумеется не дано понять всю силу таких решений.Вместо этого они будут лечить про одну платформу, the one and the only. Зато если захочется освоить неколько платформ - с таким подходом проще повеситься на сетевом шнуре. А завязываться на одну платформу и одного вендора - это примерно как совать голову в петлю в надежде на то что палач - добрый малый.