URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 84450
[ Назад ]

Исходное сообщение
"Сравнение производительности GCC и LLVM-Clang"

Отправлено opennews , 07-Май-12 23:59 
Ресурс Phoronix провёл (http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc) тестирование производительности приложений, собранных при помощи компиляторов GCC 4.6.3, GCC 4.7.0, LLVM-Clang 3.0, LLVM-Clang 3.1 SVN и Open64 5.0 (http://www.opennet.me/opennews/art.shtml?num=32275) на ноутбуке с восьмиядерным процессором Intel Core i7. В 8 тестах (http://openbenchmarking.org/result/1204215-SU-LLVMCLANG23) быстрее оказался GCC. В 4 тестах (7-Zip, скорость сборки PHP, Minion Graceful и Apache Benchmark) с незначительным отрывом в лидеры выбился Clang.

URL: http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc
Новость: http://www.opennet.me/opennews/art.shtml?num=33789


Содержание

Сообщения в этом обсуждении
"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 07-Май-12 23:59 
допилят еще clang

"Сравнение производительности GCC и LLVM-Clang"
Отправлено paulus , 08-Май-12 00:09 
да пусть пилят, только и GCC на месте не стоит...

"Сравнение производительности GCC и LLVM-Clang"
Отправлено архитектор , 08-Май-12 06:54 
> да пусть пилят, только и GCC на месте не стоит...

Нужно уметь видеть не только скорость движения, и уж тем более не только сам факт наличия хоть какого-то движения. Нужно уметь видеть траекторию пути. А с этим у большинства очень туго.

Продуманность архитектуры llvm/clang против бардака gcc.
Это как набирание скорости clang'ом по шоссе, пусть даже извилистому -
против стремления gcc ломиться напрямую и через лес.
Пусть даже пока и выше, по инерции, у gcc эта скорость "не стояния на месте".

Надо видеть качество, а не только количество.

Не в обиду gcc - он все-таки был один из пионеров в области мультиязыковых компиляторов.
Просто такова история - следующие учатся на ошибках предыдущих.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено MiG , 08-Май-12 11:02 
> Продуманность архитектуры llvm/clang против бардака gcc.
> .....
> Надо видеть качество, а не только количество.

Когда clang станет поддерживать такое же количество аппаратных и программных платформ (со всеми присущими им косяками и фичами) как и GCC вот тогда и будет уместно сравнивать их архитектуру, производительность, бардак и т.п..


"Сравнение производительности GCC и LLVM-Clang"
Отправлено архитектор , 08-Май-12 11:26 
>> Продуманность архитектуры llvm/clang против бардака gcc.
>> .....
>> Надо видеть качество, а не только количество.
>
> Когда clang станет поддерживать такое же количество аппаратных и программных платформ (со всеми присущими им косяками и фичами) как и GCC вот тогда и будет уместно сравнивать их архитектуру, производительность, бардак и т.п..

Вот очередное "чудо" мышления.
Как не пытаются думать о качестве, все равно у них получается только в плоскости количества, до этого была "скорость", теперь "количество платформ".

На этот раз оказывается, что качество архитектуры определяется якобы _количеством_ поддерживаемых платформ.
То есть, значит, именно так: стоит перенести на как можно большее количество платформ, и качество возникнет само собой.

А я-то, наивный, думал, что чем качественнее проработана архитектура, тем легче будет переносить на разные платформы, а не наоборот. А оно ведь вон как оказывается. ))))


"Сравнение производительности GCC и LLVM-Clang"
Отправлено filosofem , 08-Май-12 12:33 
>Вот очередное "чудо" мышления.
>Как не пытаются думать о качестве, все равно у них получается только в плоскости количества, до этого была "скорость", теперь "количество платформ".

Вы, любезный, сильно не обижайтесь, но это у вас ГСМ. Ваше "качество" и "архитектура" нужно как-то спроецировать в количественные характеристики, хотя бы как это сделано в сабже. Без этого ваши теоретизирования о "качестве" не более обоснованы, чем испускание газов в небольшой водоем.
>А я-то, наивный, думал, что чем качественнее проработана архитектура, тем легче будет переносить на разные платформы, а не наоборот.

Вам вот что пытаются сказать: Мы имеем две программы одна обладает функциями A, B, ... ,W, а вторая только A с оговорками и при этом работает немного быстрее, но готовит более тормозной код. Это ситуация на данный момент времени. Вполне логично предположить, что, обрастая функционалом, программа будет работать только медленнее и количество граблей и костылей в ней будет увеличиваться.  
Так что пилите и портируйте ваш ЛЛВМ-Шланг. Когда допилите потестируем и сравним и сделамем вывод, какая архитектура молодежнее и качественнее. Сейчас это несколько преждевременно делать.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено архитектор , 08-Май-12 14:48 
> Вы, любезный, сильно не обижайтесь, но это у вас ГСМ. Ваше "качество" и "архитектура" нужно как-то спроецировать в количественные характеристики, хотя бы как это сделано в сабже. Без этого ваши теоретизирования о "качестве" не более обоснованы, чем испускание газов в небольшой водоем.

Это у вас стереотипы марксистской диалектики.

Не любое количество переходит в качество.
Не любое качество выражается количественно.

Во времена расцвета компьютерной математики крайне полезно знать, что числовые системы (эти ваши количества) - это всего лишь очень частный случай из всех возможных математических и вообще концептуальных систем. Так что качество вообще может выражаться без каких либо количеств. К.Маркс отдыхает.

Хотя, если для вас это всего лишь голые теории, спите спокойно дальше.

> Вам вот что пытаются сказать: Мы имеем две программы одна обладает функциями A, B, ... ,W, а вторая только A с оговорками и при этом работает немного быстрее, но готовит более тормозной код. Это ситуация на данный момент времени. Вполне логично предположить, что, обрастая функционалом, программа будет работать только медленнее и количество граблей и костылей в ней будет увеличиваться.

Опять таки, смотря как именно она будет обрастать функционалом.
Я уже сказал, что вы видите лишь наличие движения, но не видите траектории.

> Так что пилите и портируйте ваш ЛЛВМ-Шланг. Когда допилите потестируем и сравним и сделамем вывод, какая архитектура молодежнее и качественнее. Сейчас это несколько преждевременно делать.

Ну оно конечно продолжает "пилиться", как и весь остальной софт.
Только уже давно протестировано и реально используется. Если вы проспали, ничем помочь не могу. Ждите, когда появятся ваши любимые "количества", без которых вы никак не можете.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено filosofem , 08-Май-12 17:33 
>Это у вас стереотипы марксистской диалектики.

Сами начали. Я на методологическую ошибку указал и не собирался поддерживать религиозную демагогию про количесва, качества и их переходы и непереходы.

>Так что качество вообще может выражаться без каких либо количеств. К.Маркс отдыхает.

Выражайте сколько угодно. Вы же утверждаете, что одна архитектура качественнее, продуманней, эффективнее и правильнее другой, а это уже не имеет смысла без количественного сравнения.

>Опять таки, смотря как именно она будет обрастать функционалом.
>Я уже сказал, что вы видите лишь наличие движения, но не видите траектории.

И тут конечно следует пояснить чем одна траектория настолько принципиально лучше другой, кроме лицензии. И обосновать почему все должны обязательно ходить вашей траекторией, а не выбирать самостоятельно какая им нужнее.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено архитектор , 08-Май-12 19:00 
>>Это у вас стереотипы марксистской диалектики.
>
> Сами начали.

Ничего подобного. Читайте внимательно посты. На что именно я ответил в первом посте, и как именно ответил. И как отвечал далее.

>и не собирался поддерживать религиозную демагогию про количесва, качества и их переходы и непереходы.

Назвались груздем - полезайте в кузов. И дело вовсе не в вашем нике.
Вот где вы начали:
<цитата>Ваше "качество" и "архитектура" нужно как-то спроецировать в количественные характеристики, хотя бы как это сделано в сабже.</цитата>
И не надо на меня стрелки переводить.

> Я на методологическую ошибку указал

Ваш анализ якобы методологических ошибок базировался на следующем вашем утверждении.

> Вам вот что пытаются сказать: Мы имеем две программы одна обладает функциями A, B, ... ,W, а вторая только A с оговорками и при этом работает немного быстрее, но готовит более тормозной код. Это ситуация на данный момент времени. Вполне логично предположить, что, обрастая функционалом, программа будет работать только медленнее и количество граблей и костылей в ней будет увеличиваться.
>>
>>Опять таки, смотря как именно она будет обрастать функционалом.

Ну я вам уже ответил, это зависит от того, как именно будет изменяться функционал.
И никак не логично предполагать из поставленных вами условий, что будет именно такое следствие.

Основная ваша ошибка здесь, что вы безусловно постулируете, что главным критерием является якобы опять-таки скорость работы. Правильность - безусловно, но это опять-таки не количественная характеристика, и она не определяется тупо количеством ошибок. Ибо что есть ошибка?

>>Так что качество вообще может выражаться без каких либо количеств. К.Маркс отдыхает.
>
> Выражайте сколько угодно. Вы же утверждаете, что одна архитектура качественнее, продуманней, эффективнее и правильнее другой, а это уже не имеет смысла без количественного сравнения.

Вот опять нет! Читайте внимательно посты. Вам просто кажется, что я так говорил, потому что вы только так умеете мыслить, и считаете ваш образ мышления единственно возможным.

Единственное место, где я позволил себе сравнить две архитектуры, была моя фраза:
  - Продуманность архитектуры llvm/clang против бардака gcc. - здесь нет никаких количественных сравнений, если будете утверждать, что якобы есть, то вы просто ничего не понимаете в проектировании софта.
Дальше моя фраза:
  - Пусть даже пока и выше, по инерции, у gcc эта скорость "не стояния на месте". - здесь лишь допущение позиции оппонента, рассуждение от противного.

Единственное место, где я допустил вообще сравнительную степень прилагательных:
  - ...чем качественнее проработана архитектура, тем легче будет переносить на разные платформы, а не наоборот. - но здесь я не сравнивал архитектуры, как вы утверждаете.

И уж нигде не было слов "эффективнее и правильнее", как вы утверждаете.
И качество я нигде не сравнивал. Я лишь говорил:
  - Надо видеть качество, а не только количество.
И про "траектории", см. ниже.

Далее, из следующих и прочих моих фраз:
  - Не любое количество переходит в качество.
  - Не любое качество выражается количественно.
никак не следует, что качество вообще никогда не может определяться количеством, надо лишь знать, когда именно. Но вы этого не знаете, если утверждаете:
>> <...> а это уже не имеет смысла без количественного сравнения.
>> Ваше "качество" и "архитектура" нужно как-то спроецировать в количественные характеристики, хотя бы как это сделано в сабже.

То есть вы утверждаете, что якобы всегда нужны количественные оценки.
А я лишь утверждаю, что не всегда, и даже не нужно в подавляющем количестве случаев.
Так что у меня все логично.

>>Я уже сказал, что вы видите лишь наличие движения, но не видите траектории.
>
> И тут конечно следует пояснить чем одна траектория настолько принципиально лучше другой, кроме лицензии. И обосновать почему все должны обязательно ходить вашей траекторией, а не выбирать самостоятельно какая им нужнее.

Ну видите, вы опять в плоскости лучше-хуже. Вы просто не умеете по-другому. И мне пытаетесь это приписывать, хотя я говорю совсем не так.

Почему это по-вашему следует пояснять, чем траектории лучше или хуже?
Видимо вам не известно, что разные траектории ведут _через_ разные и _в_ разные места.
И здесь снова нет никаких количественных сравнений.

-----------------
Будете утверждать, что все это якобы теории и демагогия?
Как вам угодно.
Только все эти теории успешно "прошиваются" в системы искусственного интеллекта.
Но вы лучше продолжайте дальше спать, так вам будет спокойнее.

P.S. Видите, какую злую шутку играет с вами ваш образ мышления. Вам кажется, что все люди говорят и думают так же, как вы, даже если ничего подобного они не говорили.

P.P.S. Такой подробный анализ я сделал в виде исключения, исключительно "ради вас". У вас хотя бы получается хоть немного думать. Тем же "грамотеям", кто вообще думать не в состоянии, я ответил по-проще.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено filosofem , 08-Май-12 19:41 
>Назвались груздем - полезайте в кузов. И дело вовсе не в вашем нике. Вот где вы начали <цитата>Ваше "качество" и "архитектура" нужно как-то спроецировать в количественные характеристики, хотя бы как это сделано в сабже.</цитата> И не надо на меня стрелки переводить.

Почему не надо, я же вам отвечал на всши рассуждения про качества. Если хотите религии, пожалуйста: от количество вы никуда не убежите, обладание каким-либо качеством тоже является количественной характеристикой, количество может равняться 0, а может единице. =)

>Ваш анализ якобы методологических ошибок базировался на следующем вашем утверждении.

Методологическая ошибка в том, что вы хотите провести количественное сравнение без количественных шкал. Именно количественное. Если вы утверждаете, что одна из архитектур предпочтительнее, это количественное сравнение. Без количества можно говорить только об идентичности или не идентичности двух архитектур или с некоторой натяжкой об их подобии.

С другой стороны если вы утверждаете, что вы этого не утверждали и архитектура Шланге не лучше, не молодежнее, не православнее, не эффективнее и не продуманнее ГЦЦ, то о чем вы вообще спорите? =)


"Сравнение производительности GCC и LLVM-Clang"
Отправлено архитектор , 08-Май-12 20:17 
>>Назвались груздем - полезайте в кузов. И дело вовсе не в вашем нике. Вот где вы начали <цитата>Ваше "качество" и "архитектура" нужно как-то спроецировать в количественные характеристики, хотя бы как это сделано в сабже.</цитата> И не надо на меня стрелки переводить.
>
> Почему не надо, я же вам отвечал на всши рассуждения про качества.

А я отвечал на рассуждения про количества, еще до вас.
Почему вам можно отвечать, а у меня якобы сразу демагогия, как только я вам возразил.

> Если хотите религии, пожалуйста: от количество вы никуда не убежите,

Из того, что для вас математика и информатика - религия, а сама математика для вас состоит исключительно из численных систем, следует, что у вас ярко выраженный гуманитарный склад мышления, но вы упорно встреваете в технические области.

> обладание каким-либо качеством тоже является количественной характеристикой, количество может равняться 0, а может единице. =)

Я уже сказал, что я знаю, что это не так. Хотя ваше право считать по-другому.
Оно может вообще не выражаться числами.
Просто вы видимо, кроме чисел, других информационных и математических систем не знаете.

> Методологическая ошибка в том, что вы хотите провести количественное сравнение без количественных шкал. Именно количественное. Если вы утверждаете, что одна из архитектур предпочтительнее, это количественное сравнение.

С каких это пор "предпочтение" обязано выражаться исключительно количественно?

И еще раз, я нигде не утверждал того, что вы мне здесь приписываете.
Свои высказывания я подробно разобрал в предыдущем посте, повторяться не буду.

> Без количества можно говорить только об идентичности или не идентичности двух архитектур или с некоторой натяжкой об их подобии.

Очередная глупость и невежество. Просто догма. И еще будете рассказывать мне про "религию".

> С другой стороны если вы утверждаете, что вы этого не утверждали и архитектура Шланге не лучше, не молодежнее, не православнее, не эффективнее и не продуманнее ГЦЦ, то о чем вы вообще спорите? =)

Кажется, до вас начало доходить, что я мог утверждать что-то другое.

Сто раз уже сказал, о чем.
Для тех, кто в бункере повторяю: я говорил о том, что
"нужно смотреть не только на количество, но и на качество".

Из этого никак не следует то, что вы перечислили.

Я уже сказал, что вы просто не можете мыслить иначе, поэтому вам кажется, что по-другому якобы невозможно.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено filosofem , 08-Май-12 20:45 
>>> С другой стороны если вы утверждаете, что вы этого не утверждали и архитектура Шланге не лучше, не молодежнее, не православнее, не эффективнее и не продуманнее ГЦЦ, то о чем вы вообще спорите? =)
>Кажется, до вас начало доходить, что я мог утверждать что-то другое.

Отрекаетесь от идейного превосходства продуманности и эффективности архитектуры Шланге, уже прогресс. Продолжаем.


>Сто раз уже сказал, о чем. Для тех, кто в бункере повторяю: я говорил о том, что "нужно смотреть не только на количество, но и на качество".

Эта фраза ни о чем, вы это понимаете?
Вы хотите сказать, что архитектура шланге обладает неким "качеством", которым не обладает гцц, но при этом она не лучше не православнее, не эффективнее и не продуманнее. Так? =))))

Кстати вы не путаете качество в понимании религии Иисуса^W Маркса и качество в понимании отдела контроля качества? Они никак не связаны если что.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено архитектор , 09-Май-12 04:28 
>>Кажется, до вас начало доходить, что я мог утверждать что-то другое.
>
> Отрекаетесь от идейного превосходства продуманности и эффективности архитектуры Шланге, уже прогресс.

Зачем мне отрекаться, от того с чем я и не был никак связан.
Читайте внимательно, что я писал, и на какие высказывания я отвечал. А пока вы продолжаете заниматься приписками.

Я лишь с самого начала заявлял, что глупо судить об идейном превосходстве по скорости работы, количеству инсталляций, клоичеству поддерживаемых платформ, и прочим "количествам".

Как у вас тут получается "идея превосходства clang", и почему вы не видите других вариантов - это вы сами разбирайтесь.

См. ниже о моей единственной фразе касательно clang.

> Продолжаем.

Вам следовало бы сначала разобраться со своими старыми ошибками, прежде чем продолжать делать новые. Тоже мне, "филосов".

>>Сто раз уже сказал, о чем. Для тех, кто в бункере повторяю: я говорил о том, что "нужно смотреть не только на количество, но и на качество".
>
> Эта фраза ни о чем, вы это понимаете?

Если она для вас "ни о чем", то это не значит, что она вообще такова.
И вы, и многие другие ораторы, никак не можете выйти из плоскости количественных оценок.

Так что вышеуказанная моя фраза в этом контексте очень даже "о чем".

И еще. На ваш вопрос из предыдущего поста типа, "о чем же вы тогда спорите, если не о превосходстве clang". Так вот об этом как раз. Что вы никак не можете выйти в своем мышлении за пределы численных систем и всяких там "количеств". С самого начала об этом и говорю, еще до вашего появления.

А вы все "о чем", да "о чем". Не видите, что у вас "под носом".

> Вы хотите сказать, что архитектура шланге обладает неким "качеством", которым не обладает гцц, но при этом она не лучше не православнее, не эффективнее и не продуманнее. Так? =))))

И не только одним "качеством". Просто остановились на одном.
Но при чем здесь "православие"?
И при чем здесь "лучше-хуже"?

Я сказал так:
"Продуманность архитектуры llvm/clang против бардака gcc."

Естественно, эта мысль была сильно упрощена с учетом аудитории, для которой она говорилась, и в целях краткости. Но суть от этого не меняется. Просто с более строгой точки зрения следует сравнить более детально конкретные компоненты и подсистемы обсуждаемых творений. И в gcc тоже много чего "продумано". Просто чисто исторически, в clang "продуманы" системы, которые в gcc создавались хаотично. Это нормально, когда учатся на ошибках своих предшественников. Я уже обозначил эту мысль в самом первом своем посте.

Однако по-прежнему даже в этом случае какие-либо количественные оценки потребуются не часто. При чем здесь "лучше-хуже", "больше-меньше"?

А больше про clang я ничего не говорил. Все остальное - плод вашего воображения под воздействием эмоций, а не разума.

Эффективность тоже не обязана выражаться количественно.
А уж откуда у вас берутся такие словечки, как "правостлавность" и "молодежность".
Только из гуманитарного склада вашего мышления.

Но вы хотя бы попытались использовать разум.
Остальные вообще сразу вошли в эмоциональный ступор, как только речь зашла о чем-то другом, кроме "количеств" и "скоростей".

> Кстати вы не путаете качество в понимании религии Иисуса^W Маркса и качество в понимании отдела контроля качества? Они никак не связаны если что.

Похоже это вы совсем запутались, и уже не знаете, что с чем связать.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 11:46 
>Продуманность архитектуры llvm/clang против бардака gcc.

Ахаха! Аналитик с ЛОРа, не иначе. Не видел кода не там, ни там, а кукарекает еще об архитектурах.
llvm выгодна только эплу, чтоб код скрывать. Вот и все различие.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено _yurkis_ , 08-Май-12 12:23 
>>Продуманность архитектуры llvm/clang против бардака gcc.
>Ахаха! Аналитик с ЛОРа, не иначе. Не видел кода не там, ни там, а кукарекает еще об архитектурах.

Я код видел. Могу подтвердить слова этого товарища. А Вы?

>llvm выгодна только эплу, чтоб код скрывать. Вот и все различие.

Вот это умозаключение как раз спалило Вас, уважаемый. На ЛОРе такого понабрались?

clang нужен как минимум:
1. FreeBSD- ну понятно...
2. Куче коммерческих контор (Adobe там, еще кто- то)
3. Гуглю (AddressSanitizer для тестирования хрома, если чего).
4. Чем там в открытых дровах видеокарт шейдеры, OpenCL и т.п. компилируется?
5. Очень много кому еще

Кстате, об AddressSanitizer, статическом анализаторе LLVM и еще некоторых плюшках настоятельно советую погуглить. Может тогда Вы отбросите религию и LLVM будет полезна и Вам тоже.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Куяврик , 08-Май-12 14:08 
Не всем дано вот так просто отбросить религию :)

"Сравнение производительности GCC и LLVM-Clang"
Отправлено kurokaze , 08-Май-12 15:21 
Тут в топике и религиозных фанатиков clang-а хватает. Но они себя конечно такими не считают нибожеж мой

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Куяврик , 08-Май-12 16:43 
> Тут в топике и религиозных фанатиков clang-а хватает. Но они себя конечно такими не считают нибожеж мой

Хватает для чего? clang пилится, пилится активно, имеет некоторые успехи и в общем явно помлаже, чем гцц. Если люди считают, что переспектива - есть, это что - фанатизм?

Если не устраивает лицензия ГНУ и люди рады, что есть альтернатива, это что - фанатизм?

Если вы не об этих двух случаях, то о чём?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 08-Май-12 16:44 
> Если не устраивает лицензия ГНУ

вот это-то и подозрительно.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Куяврик , 08-Май-12 16:56 
> вот это-то и подозрительно.

Это очень подозрительная подозрительность.

http://www.gnu.org/licenses/license-list.html

Смотрим список свободных лицензий и видим что их там сильно больше одной, и совсем не все начинаются с GPL*.

Ну дальше я могу по десятому разу рассказать что код BSD был, есть и будет открытым, но как и предыдущие разы фанатизм твой будет непокобелим :)


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 08-Май-12 17:12 
знаешь, что это мне напоминает? примерно такой диалог:
— давай начинать дело!
— давай, только договор составим.
— да ты чо, зачем нам договор, мы же друзья!
— то есть, ты меня обмануть хочешь?
— нет, конечно!
— тогда давай договор.
— но мы же друзья!
(это я не про наш диалог, если кто не понял)

если не собираются делать проприетарный закрытый форк — то почему не GPL? «мы же друзья»?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Куяврик , 08-Май-12 17:49 
> если не собираются делать проприетарный закрытый форк — то почему не GPL?

ты сейчас вот так абстрактно говоришь? если да - то в принципе да, почему бы и не gpl.
если конкретно - то и конкретно надо смотреть. возможно, используются наработки, несовместимые с GPL. возможно, есть исторические причины.

опять таки вопрос - мы будем позволять брать наш открытый код, чтобы _на его основе_, кто-то добавив _свой_ код мог этот код не публиковать? ты против. мне например, пофиг. мне не жалко. на наш проект это никак не повлияет. так что, кроме "взять и закрыть" есть множество нюансов.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 19:23 
> возможно, есть исторические причины.

Да, у эппла есть исторические причины: они как-то так исторически любят зажимать все что зажимается, а выбрасывают на публику только наименее ценные объедки.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено _yurkis_ , 08-Май-12 21:44 
>> возможно, есть исторические причины.
> Да, у эппла есть исторические причины: они как-то так исторически любят зажимать
> все что зажимается, а выбрасывают на публику только наименее ценные объедки.

Вас это беспокоит? Кто должен решать что Apple делать со СВОИМ кодом?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 09-Май-12 01:40 
> Вас это беспокоит? Кто должен решать что Apple делать со СВОИМ кодом?

Да, при принятии решения закладываться ли мне на тул или нет - меня очень даже беспокоит: будет потом кидалово так что мне придется самому разгребать свои проблемы, или же на апстрим можно положиться. На FSF я как-то охотнее положусь чем на эппл. А они пусть там решают что им делать с их кодом наздоровьице.



"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 09-Май-12 11:32 
>> Вас это беспокоит? Кто должен решать что Apple делать со СВОИМ кодом?
> Да, при принятии решения закладываться ли мне на тул или нет -
> меня очень даже беспокоит: будет потом кидалово так что мне придется
> самому разгребать свои проблемы, или же на апстрим можно положиться. На
> FSF я как-то охотнее положусь чем на эппл. А они пусть
> там решают что им делать с их кодом наздоровьице.

ну да FSF один раз кинул всех - начав присваивать себе код, кинул еще раз когда DWG библиотеку отказался отпустить под LGPL - хотя разработчики это просили, кинет тебя и третий раз и будет за тебя решать как поступать с твоей работой. Но ты хавай что дают - хавай.
И свято верь что все будет как есть.

В то же время apple придерживается той лицензии на которой взяла себе код - и патчи для Object-C все так же доступны на сайте apple под оригинальной GPL v2. Не больше не меньше - ровно под той лиценизией под которой взяли.
Хотя да, сейчас это не надо - проще вложиться в Clang - который не будет творить безобразий с лицензированием, как их творил FSF.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 09-Май-12 15:03 
какие вы смешные, роботы.

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 10-Май-12 16:20 
> ну да FSF один раз кинул всех - начав присваивать себе код,

Цели и задачи FSF мне понятны. Как и цели эппла. Вот только если цель FSF ака "доступность кода для всех" и "возможность затыкать лазейки найденные в старых лицензиях ушлыми корпорасами" - они и понятны и в ряде случаев вполне приемлимы для меня, а иногда даже и симпатичны, так что возражений сие не вызывает. А цели эппла - беспринципная рубка бабла, в том числе и на чужом труде. А вот это уже можно делать по разному. Вплоть до строительства счастья акционеров на чужих костях. Не говоря уж о такой мелочи как эксклюзивное выдвижение себя и попрание конкурентов.

Опенсорс сам по себе - это инструмент не попрания конкурентов. Это инструмент коллаборации. Попрание конкурентов в стиле эппла ("а вот тут мы зажмем, а вот это не дадим, и вообще, всю команду к себе перетянем") - это декоративная хрень, а не опенсорс. Толку то с вываленных сорцев если вся команда пляшет под дудку эппла и радостно щемит хвосты всем кто не эппл? Яркий тому пример - дарвин. Обратите внимание, все остальные производители мобил решили что им такой апстрим не требуется. И выбрали апстримом ведроида. Потому что сие проще чем дарвинячий кернел лично на ARM портировать...

> кинул еще раз когда DWG библиотеку отказался отпустить под LGPL -
> хотя разработчики это просили,

Зажиматели сорцев негодуют. Ну нормально - все хотят core либу нашару, налабать вокруг нее обвязки по бырому и рубать капустку, ни с кем не делясь, да? При том что всю сложную работенку другие сделали? :)

> за тебя решать как поступать с твоей работой.

Вот вы выше между прочим за FSF решаете как им с их работой поступить, но им почему-то за то же самое пеняете. И если их цели и задачи мне понятны и возражений не вызывают то ваша цель - это по бырому навариться на чужом труде, ни к воем случае ничем не делясь с теми кто сделал львиную долю работы. Все должно достаться тому кто налепил по бырому glue-code вокруг либы и набрался наглости, конечно.

> В то же время apple придерживается той лицензии на которой взяла себе код

... и что из этого выходит с тем же дарвином - уже все видели. Поэтому если хочется операционку и чтоб на ARM - это будет ну уж точно не дарвин. А линукс. Интересно, почему бы это.

А для меня outcome следующий:
- Я могу взять линь и доработать под некую железку без особых усилий. Thx to FSF. Без их компилера и лицензий это не вышло бы.
- А с жопплом я могу только поффтыкать на их кульные железки. А что-то поменять - ни-ни-ни! Это ж только богам из Купертино можно. Но чисто декоративно - божки поиграли в добрых парней и бросили кость.

> - и патчи для Object-C все так же доступны на сайте apple под оригинальной GPL v2.
> Не больше не меньше - ровно под той лиценизией под которой взяли.

Так пользуйтесь наздоровье. А они решили что им GPLv3 нужен. Потому что нашлись умними которые заворкэраундили ряд пунктов GPL, так что формально все честно а реально цель лицензии не достигнута. Что по идее может вызывать недовольство разработчиков, ведь они выбирают лицензия для достижения своих целей. Если цели достигаться перестают, потому что особо хитрые вертихвосты нашли воркэраунд - так это плохо, да.

> Хотя да, сейчас это не надо - проще вложиться в Clang -
> который не будет творить безобразий с лицензированием, как их творил FSF.

А кто гарантирует что история с дарвином не повторится в случае шланга, если яппл решит что "а вон те му...ки с нами конкурируют нащим же компилером"? При том что весь девтим шланга в яппле - воткнуть лом в вентилятор конкурента им будет совершенно не вопрос.

Впрочем, меня такой расклад устраивает. Это означает что фрибсды никогда не будет на десктопе всерьез. Потому что если кто рискнет здоровьем хвост задрать и побежать к успеху - быстро словит лом в вентилятор. Своего то девтима нет, а чужой подконтролен конторе с коммерческим интересом. Так что лом в вентилятор не заржавеет, just in case. Вы ж не сомневаетесь что девтим который содержит только эппл может и будет делать изменения удобные эпплу даже если они все ломают нахрен у всех остальных? :)


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 10-Май-12 18:46 

>> кинул еще раз когда DWG библиотеку отказался отпустить под LGPL -
>> хотя разработчики это просили,
> Зажиматели сорцев негодуют. Ну нормально - все хотят core либу нашару, налабать
> вокруг нее обвязки по бырому и рубать капустку, ни с кем
> не делясь, да? При том что всю сложную работенку другие сделали?
> :)

негодуют многие GPL v2 лицензированые САПР. но вам кэп этого не понять - за вас уже Столман подумал, и все вам рассказал.


>[оверквотинг удален]
> glue-code вокруг либы и набрался наглости, конечно.
>> В то же время apple придерживается той лицензии на которой взяла себе код
>> - и патчи для Object-C все так же доступны на сайте apple под оригинальной GPL v2.
>> Не больше не меньше - ровно под той лиценизией под которой взяли.
> Так пользуйтесь наздоровье. А они решили что им GPLv3 нужен. Потому что
> нашлись умними которые заворкэраундили ряд пунктов GPL, так что формально все
> честно а реально цель лицензии не достигнута. Что по идее может
> вызывать недовольство разработчиков, ведь они выбирают лицензия для достижения своих целей.
> Если цели достигаться перестают, потому что особо хитрые вертихвосты нашли воркэраунд
> - так это плохо, да.

так почему FSF начинает требовать чтобы apple перелицензировало под GPL v3 код который они написали под GPL v2? Кто такие FSF что бы указывать и требовать у авторов выбирать только "нужную" им лицензию?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 10-Май-12 19:00 
> негодуют многие GPL v2 лицензированые САПР.

а не надо было читерить, вот и всё. как именно использовать GPL — в ней написано. если кто-то посчитал, что хочет по-другому — на здоровье, но пусть не вякает: поддерживать читы и воркэраунды FSF не обязывалось.

> так почему FSF начинает требовать чтобы apple перелицензировало под GPL v3 код
> который они написали под GPL v2?

чтобы включить его в состав gcc и поддерживать. и не «требовали» а «предложили». огрызок не захотел. товарищи из gcc пожали плечами и сказали, что ССЗБ.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 11-Май-12 14:01 
> а не надо было читерить, вот и всё. как именно использовать GPL — в ней написано. если кто-то посчитал, что хочет по-другому — на здоровье, но пусть не вякает: поддерживать читы и воркэраунды FSF не обязывалось.

Использовать GPL v2 only - это читерство? какие вы глупые вьюноша.
Поддерживать сексуальные фантазии FSF - что они там придумают в новых версиях - это не логично.
Так же как и навязывать пользователям библиотеки какие-то доп условия.
Вот люди пожали плечами - и linux world остался без сапра который читает DWG.
собственно кто проиграл? только ваш убогий FSF & linux world.


> чтобы включить его в состав gcc и поддерживать. и не «требовали» а «предложили». огрызок не захотел. товарищи из gcc пожали плечами и сказали, что ССЗБ.

ты старательно забываешь - что именно требовали.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 08-Май-12 22:03 
> ты сейчас вот так абстрактно говоришь?

нет, я сейчас конкретно говорю.

> мне например, пофиг.

раз пофиг — то почему не GPL? если тебе *действительно* пофиг.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Клыкастый , 09-Май-12 07:35 
>> ты сейчас вот так абстрактно говоришь?
> нет, я сейчас конкретно говорю.

Конкретно какой проект ты имеешь в виду?


>> мне например, пофиг.
> раз пофиг — то почему не GPL? если тебе *действительно* пофиг.

Ещё раз: мне пофиг, что будут делать с кодом те, кто его возьмут за основу. Возможно, они его захотят в какой-то проект с экзотической лицензией впилить.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 09-Май-12 15:05 
>>> ты сейчас вот так абстрактно говоришь?
>> нет, я сейчас конкретно говорю.
> Конкретно какой проект ты имеешь в виду?

конкретно llvm+clang.

>> раз пофиг — то почему не GPL? если тебе *действительно* пофиг.
> Ещё раз: мне пофиг, что будут делать с кодом те, кто его
> возьмут за основу.

следовательно, тебе пофиг и какая лицензия. потому что *тебе пофиг*. тогда почему не GPL? а если «GPL не позволит» и ты пы — то тебе совершенно не «пофиг», и ты лукавишь.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 10-Май-12 16:22 
> то тебе совершенно не «пофиг», и ты лукавишь.

Охренеть. Кэп поймал клыкастого тролля в эпичнейшую логическую ловушку. Снимаю шляпу, это просто шедеврально :)


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Куяврик , 16-Май-12 15:17 
Странно потёрли ответ. Восстанавливаю.

>> Конкретно какой проект ты имеешь в виду?
> конкретно llvm+clang.

конкретно в этом проекте разработчики уже выбрали лицензию.

> следовательно, тебе пофиг и какая лицензия.

именно так.

> тогда почему не GPL?

потому что лицензия в данном случае уже выбрана. если проект пишется "с нуля" - не вижу причин не рассматривать как вариант gpl.

>  а если «GPL не позволит» и ты пы —

если будет участие разработчиков, которые окажут помощь проекту, но захотят использовать наработки под другой лицензией - не вопрос.

> то тебе совершенно не «пофиг», и ты лукавишь.

меньше думай за других - точнее будут оценки.



"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 16-Май-12 20:35 
я вообще ни за кого не думаю, я лишь читаю то, что написано. моя ли вина, что написано было криво?

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 19:24 
> Если не устраивает лицензия ГНУ

Да. Зажимать сорцы мешает. Ну как бы удачи в бесплатной работе на любителей зажимать сорцы :)


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 08-Май-12 16:39 
> clang нужен как минимум:

(далее следует список коммерческих контор и бсдошники, которым GPL как кол в анусе)


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Куяврик , 08-Май-12 17:10 
похоже кол называется BSD и причиняет печальку тебе :)

"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 08-Май-12 17:15 
> похоже кол называется BSD и причиняет печальку тебе :)

мне всё равно, меня шланг не устраивает по другим причинам. как минимум — он не поддерживает вложеные функции. пуристы могут до посинения орать, что это не нужно, конечно — на здоровье. только gcc их поддерживает, существует под кучу архитектур и ОС. выбор очевиден.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 19:20 
> похоже кол называется BSD

Пока что я вижу как *bsd и прочие проприетарные *никсы повылетали почти отовсюду. Куда этим древностям и дорога.



"Сравнение производительности GCC и LLVM-Clang"
Отправлено Клыкастый , 09-Май-12 07:51 
> Пока что я вижу как *bsd и прочие проприетарные

это ты у себя в репке не смотрел. а ты посмотри повнимательнее, да вычисти всё не-gpl-ное. вот  это будет настоящее вегетарианство.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 10-Май-12 16:24 
> да вычисти всё не-gpl-ное. вот  это будет настоящее вегетарианство.

А если я вычищу все GPLное, у меня система не будет бутявиться и ее будет нечем собирать. Какая ж система без ядра и компилера? :)

А с вашими ядрами и компилерами мои системы работать не будут, да. Потому что у вас как обычно поддержка армов и мипсов - только ан бумаге и с такими как вы каши не сваришь.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 10-Май-12 16:57 
(тихонечко) он не фанат-бсдшник. только никому не говори.

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Куяврик , 11-Май-12 09:27 
> А с вашими ядрами и компилерами мои системы работать не будут, да.
> Потому что у вас как обычно поддержка армов и мипсов -

http://www.netbsd.org/ports/

> только ан бумаге и с такими как вы каши не сваришь.

чуть-чуть предмет получше представляй и всё будет окей.



"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 19:21 
> похоже кол называется BSD и причиняет печальку тебе :)

Ну так ты такой веселый, расскажи где твое коммерческое BSDi? Что, поставщик оного на линуксы смотался потому что их свобода зажимания сорцов оказывается не проперла клиентуру? Бывает :)


"Сравнение производительности GCC и LLVM-Clang"
Отправлено _yurkis_ , 08-Май-12 21:46 
>> похоже кол называется BSD и причиняет печальку тебе :)
> Ну так ты такой веселый, расскажи где твое коммерческое BSDi? Что, поставщик
> оного на линуксы смотался потому что их свобода зажимания сорцов оказывается
> не проперла клиентуру? Бывает :)

Эмм... Помому они теперь называются ixSystems. Или я ошибаюсь?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 09-Май-12 01:44 
> Эмм... Помому они теперь называются ixSystems. Или я ошибаюсь?

Это называлось помнится WindRiver. И оно как-то нынче барыжит ... на основе embedded Linux. Такая вот фигня. Потому что пока они там зажимали сорцы и гасили друг друга, выясняя кто у кого скопипастил и кто кому задолжал, пингвин просто развивался, писав с ноля и под лицензией исключающей такие вещи.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено _yurkis_ , 10-Май-12 12:30 
>> Эмм... Помому они теперь называются ixSystems. Или я ошибаюсь?
> Это называлось помнится WindRiver. И оно как-то нынче барыжит ... на основе
> embedded Linux. Такая вот фигня.

Вобще- то они живут с продажи vxWorks. Остальное вторично. Таки да, BSDi в недрах WindRiver помер. Как и многие другие коммерческие Unix. Как, скорее всего, помрет и Solaris  в недрах Oracle.

Другая половина BSDi (не софтверная, как я понял) ныне называется ixSystems и пилит по старой памяти PC-BSD, FreeNAS да и вобще фряху.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 10-Май-12 16:34 
> Вобще- то они живут с продажи vxWorks.

Вообще-то они на коммерческой основе продают пингвины. Как раз в том числе и потому что спрос на VxWorks в ряде ниш сдувается в пользу пингвина.

> Остальное вторично.

А источник таковых данных? Я вот вижу например что пингвин почти повыпер VxWorks в всяком soho сетевом и тому подобном оборудовании, например. Наверное потому что нынче уже нет смысла экономить на флехе 2 Мб или 4Мб или раме 4Мб или 16Мб. И то и другое жуткий low end и по цене грязи под ногами. Чип и есть чип. А фич у пингвина в разы больше, сетевых протоколы пряммее реализованы и лучше отлажены, etc. Так что не удивительно что они пингвином заинтересовались. Конкуренты подпирают + клиентура требует. Если игнорировать - у конкурентов нынче сборок пингвина под эмбеддед - хоть попой жуй! Вплоть до поставки референсного ядра прямо с эвалбордой на чип. Стало быть половина клиентов просто пошлет вендора лесом. А зачем им покупать какой-то vxworks если пингвина можно нашару взять? Не, конечно есть ниши где пингвину тяжело с ним рубаться. Но это совсем нишевое нечто.

> Таки да, BSDi в недрах WindRiver помер. Как и многие другие коммерческие Unix. Как,
> скорее всего, помрет и Solaris  в недрах Oracle.

Ну так это логично. Сильный открытый конкурент где конкуренты как ни странно кооперативно работают над задачей делает все проприетарное барахло устаревшими и неконкурентоспособными. По совершенно естественным причинам: совместно вкалывать эффективнее чем рвать глотки и переизобретать велосипеды заново.

> Другая половина BSDi (не софтверная, как я понял) ныне называется ixSystems и
> пилит по старой памяти PC-BSD, FreeNAS да и вобще фряху.

К счастью это не мои проблемы уже.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено _yurkis_ , 10-Май-12 18:16 
>Я вот вижу например что пингвин почти повыпер VxWorks в всяком soho сетевом и тому подобном оборудовании, например. Наверное потому что нынче уже нет смысла экономить на флехе 2 Мб или 4Мб или раме 4Мб или 16Мб. И то и другое жуткий low end и по цене грязи под ногами. Чип и есть чип. А фич у пингвина в разы больше, сетевых протоколы пряммее реализованы и лучше отлажены, etc. Так что не удивительно что они пингвином заинтересовались. Конкуренты подпирают + клиентура требует. Если игнорировать - у конкурентов нынче сборок пингвина под эмбеддед - хоть попой жуй!

Linux не гарантирует (и никогда не будет гарантировать) время реакции на событие с точностью до такта CPU. В коммерческих встроеных системах жесткого реального времени vxWorks рулит и педалит.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 10-Май-12 18:58 
> Linux не гарантирует (и никогда не будет гарантировать) время реакции на событие
> с точностью до такта CPU.

а что гарантирует? именно с точностью до такта?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено _yurkis_ , 10-Май-12 20:14 
>> Linux не гарантирует (и никогда не будет гарантировать) время реакции на событие
>> с точностью до такта CPU.
> а что гарантирует? именно с точностью до такта?

Да


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 10-Май-12 21:16 
>> а что гарантирует? именно с точностью до такта?
> Да

что «да»? что гарантирует-то? и где об этом можно почитать? ссылочку на «с точностью до такта» можно? мне дико интересно, например.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено _yurkis_ , 11-Май-12 15:08 
>>> а что гарантирует? именно с точностью до такта?
>> Да
>что «да»? что гарантирует-то? и где об этом можно почитать? ссылочку на «с точностью до такта» можно? мне дико интересно, например.

Ссылки не дам. По работе сталкивался. (В т.ч. и с приколами типа: включив сохранение FPU контекста вы получите +n тактов при переключении контекста). По большому счету vxWorks - это статически слинкованая библиотека. Многозадачность- не вытесняющая. Почему бы ей и не гарантировать?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 11-Май-12 15:12 
ага. то есть, «фиг его знает», на самом деле.

не гарантировать, например, потому, что не все команды занимают одинаковое количество тактов. а иногда ещё прерывания могут приходить. или работать важные неразбиваемые куски.

ты, однако, написал, что «гарантирует с точностью до такта». вот мне и интересно посмотреть, какая это система такое умеет — вне зависимости от чего бы то ни было. и почему эта система ещё не завоевала мир: ведь больше так не умеет никто.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Клыкастый , 09-Май-12 06:53 
> Ну так ты такой веселый, расскажи где твое коммерческое BSDi?

Предполагается, что это такой тонкий троллинг?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 10-Май-12 16:35 
> Предполагается, что это такой тонкий троллинг?

Да, это вполне прозрачный намек что оно сыграло в ящик не выдержав конкуренцию с открытым пингвином.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Куяврик , 11-Май-12 09:50 
> Да, это вполне прозрачный намек что оно сыграло в ящик не выдержав
> конкуренцию с открытым пингвином.

А можно поинтересоваться источником данных такой пронзительной по мощности аналитики? Почему именно Линукс? А вот по моим данным прямыми конкурентами BSDi были BSD-системы, в том числе бесплатные. А ещё у них были лицензионные проблемы. Я понимаю, что нет сил, как хочется нарисовать себе лишнюю звезду на фюзеляже, но неплохо бы перед этим как-то подтвердить. То, что коммерческие UNIX медленно но верно слили открытым системам вопросов нет, но вы уверены, что это преимущество Linux над BSD, а не бесплатных открытых над платными закрытыми системами?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено _yurkis_ , 08-Май-12 21:48 
>> clang нужен как минимум:
> (далее следует список коммерческих контор и бсдошники, которым GPL как кол в
> анусе)

Chromium? Свободные драйвера видео?

Кстате, а почему Вас беспокоит анус бздюшников?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 08-Май-12 21:57 
> Chromium?

хомки помогают гуглю писать браузер. ну, вперёд, чо.

> Свободные драйвера видео?

и какие это драйвера видео собираются шлангом?

> Кстате, а почему Вас беспокоит анус бздюшников?

потому что они со своей попаболью всенепременно прибегают сюда и начинают орать.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено iZEN , 08-Май-12 22:10 
> и какие это драйвера видео собираются шлангом?

Вот эти:
% pkg_info -Ex xf86-video
xf86-video-ati-6.14.3_1
xf86-video-vesa-2.3.0_2

Другие не пробовал.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 08-Май-12 22:47 
у меня это собрано gcc. вопрос подразумевал «какие не могут обойтись без».

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 09-Май-12 02:36 
> у меня это собрано gcc. вопрос подразумевал «какие не могут обойтись без».

А у тебя что, такая же махровая некромансия? О_О


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 09-Май-12 15:02 
яблочник с gcc 4.2 detected.

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 10-Май-12 16:36 
> яблочник с gcc 4.2 detected.

Ты про изена? Если ты мне, у меня gcc 4.6.х в основном. Хорошо что я не яблочник, да :). С тех пор оптимизер у гцц подтянули весьма даже. А яблочники и прочие бздуны пусть и бодаются со своими жабами и религиями.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено _yurkis_ , 10-Май-12 12:05 
>> Chromium?
> хомки помогают гуглю писать браузер. ну, вперёд, чо.

А другие хомки помогают гуглю делать серверную ОС (свои патчи к которой гугль, кстате, никому не показывает вобще). И что?


>> Свободные драйвера видео?
> и какие это драйвера видео собираются шлангом?

Собираются как минимум intel.
Gallium3D использует llvm для компиляции шейдеов. И он не один такой.
Короче, гуглим MESA LLVM и удивляемся.

>> Кстате, а почему Вас беспокоит анус бздюшников?
> потому что они со своей попаболью всенепременно прибегают сюда и начинают орать.

Может это линуксоиды прибежали в тему о clang со своей попоболью? Типа "gcc все равно круче ва имя луны патамушта многа платформ и GPL!".


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 18:35 
>Я код видел. Могу подтвердить слова этого товарища.

Прошу великодушно. Что же такогов в коде gcc, что мешает ему развиваться как КОМПИЛЯТОР в отличии от llvm.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено _yurkis_ , 10-Май-12 12:08 
>>Я код видел. Могу подтвердить слова этого товарища.
> Прошу великодушно. Что же такогов в коде gcc, что мешает ему развиваться
> как КОМПИЛЯТОР в отличии от llvm.

Ему ничего не мешает развиваться. Просто архитектура llvm изначально была создана с прицелом на модульность с четким разделением (backend / frontend) с четко формализоваными интерфейсами. Плюс в силу молодости код clang/llvm не оброс костылями.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 13:03 
ага, нашёлся тут "видитель" качества.

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 18:55 
> только сам факт наличия хоть какого-то движения. Нужно уметь видеть траекторию
> пути. А с этим у большинства очень туго.

Надо уметь видеть траекторию пути и первую и вторую производные координат чтобы понимать куда дальше пойдет.

> Продуманность архитектуры llvm/clang против бардака gcc.

Таненбаум тоже втирал что микроядра - наше все. Ну и где они, ваши микроядра? Поэтому давайте говорить "гоп" после того как перепрыгнете :). Вот там то и было видно что траектория может задумана то и ничего, а вот со скоростями и ускорениями - не задалось.

> Надо видеть качество, а не только количество.

Ну вон Таненбаум со своим миниксом это пытался всем втереть. И где он?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 00:25 
> допилят еще clang

Говорят, Apple уже сейчас вовсю пользуется допиленным clangом. Только делиться не хочет.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Алексей , 08-Май-12 01:01 
С таким же успехом эппл может использовать допиленный gcc и ни с кем не делиться - это так, мысль на подумать.

Из всего llvm эпплу нужен только Objective-C (который допилен уже более чем достаточно).


"Сравнение производительности GCC и LLVM-Clang"
Отправлено evgeny_t , 08-Май-12 01:20 
а свое ведро чем они будут компилить ?

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Алексей , 08-Май-12 02:17 
> а свое ведро чем они будут компилить ?

Да тем же мифическим допиленным GCC или CLang :)


"Сравнение производительности GCC и LLVM-Clang"
Отправлено _yurkis_ , 10-Май-12 14:18 
> а свое ведро чем они будут компилить ?

Так хотя бы и последним gcc со своими патчами! Вы можете никогда и не узнать чем конкретно компилят OSX-IOS.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 00:24 
интересно посмотреть тесты на процессоре от amd

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Андрей , 08-Май-12 01:04 
> на ноутбуке с восьмиядерным процессором Intel Core i7

Это серьёзно? Или 4-ядерном & hyperthreading?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Тощий Тролль , 08-Май-12 02:18 
4 ядра + HT

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 13:10 
ну тогда за текст выше нужно яйца отрезать.

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 21:16 
Можно и не отрезать, но о квалификации писавшего это говорит достаточно красноречиво

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Сергей , 08-Май-12 01:10 
В большинстве тестов результаты GCC и LLVM+Clang очень близки с нулевым или небольшим перекосом в ту или иную сторону: http://openbenchmarking.org/result/1204215-SU-LLVMCLANG23

И только в паре тестов GCC ощутимо выигрывает, возможно, из-за использования MMX, SSE, AVX и т.п.

Так что LLVM+Clang уже сейчас вполне себе штучка.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 01:38 
> В большинстве тестов результаты GCC и LLVM+Clang очень близки

Не считая того что в 50% у шланга оптимизатор косячит и получается проигрыш в пару раз.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Sauron , 08-Май-12 01:41 
Косячит отсутствие openMP

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 19:19 
> Косячит отсутствие openMP

Судя по всему - не только оно.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено an. , 08-Май-12 10:55 
> Так что LLVM+Clang уже сейчас вполне себе штучка.

Действительно, проект интересный. Но пока слишком часто еще попадается "compiler internal error". Рановато пока еще...


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Сергей , 08-Май-12 01:22 
Ребята из LLVM и Clang делают очень нужное дело! Молодцы! Так держать!

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 01:43 
> Ребята из LLVM и Clang делают очень нужное дело!

Какое?



"Сравнение производительности GCC и LLVM-Clang"
Отправлено Алексей , 08-Май-12 02:16 
Делают отдельный фронт-енд для C++. Тот, что в GCC, к сожалению, отдельно от GCC использовать не удается.

"Сравнение производительности GCC и LLVM-Clang"
Отправлено AdVv , 08-Май-12 14:40 
Видимо такое-же, как в свое время делал некий Л.Торвальдс, начав писать новую ОС, хотя их и до него было написано немало.

"Сравнение производительности GCC и LLVM-Clang"
Отправлено vaychick , 08-Май-12 10:04 
>Ребята из LLVM и Clang делают очень нужное дело! Молодцы! Так держать!

Я думаю они хотят сместить GCC с лидерского места и бороться с GNU. Что еще ожидать от Apple. Даже на вики написана цель проекта

"Целью проекта является замена фронт-энда этих языков из GNU Compiler Collection (GCC). Разработка спонсируется корпорацией Apple, исходный код распространяется в рамках BSD-подобной лицензии."


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Куяврик , 08-Май-12 14:13 
>>Ребята из LLVM и Clang делают очень нужное дело! Молодцы! Так держать!
> Я думаю они хотят сместить GCC с лидерского места и бороться с GNU.

Да вы не пугайтесь расстреливать не будут.

> "Целью проекта является замена фронт-энда этих языков из GNU Compiler Collection (GCC).
> Разработка спонсируется корпорацией Apple, исходный код распространяется в рамках BSD-подобной лицензии."

Вот интересно религиозное мышление. Написано - замена. Прочитано - бороться.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено vaychick , 08-Май-12 16:07 
>Вот интересно религиозное мышление

:)

согласен - бороться добавлено от меня в сердцах. Если бы это был сторонний продукт, который предоставлял бы альтернативу и финансировался бы другой компанией, я бы порадовался, а так настораживает.

>Да вы не пугайтесь расстреливать не будут.

Поводов для паники нет, так как даже если GCC морально устареет, сообщество GNU придумает что-нибудь новое.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Куяврик , 08-Май-12 16:36 
> Поводов для паники нет,

Вообще никаких. 2 свободных компилятора лучше, чем один. Какие-то там лидирующие позиции вообще не самоцель. Так что - вполне всё отлично. Успехов и тем и тем.

> так как даже если GCC морально устареет, сообщество GNU придумает что-нибудь новое.

дык это ж отлично! не надо только дух соревнования подменять боевым.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено vaychick , 08-Май-12 16:40 
>не надо только дух соревнования подменять боевым.

Здесь вы правы.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 08-Май-12 16:43 
да и соревноваться-то пока не с кем. продукты, мягко говоря, разного калибра и направленности.

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 19:04 
> Да вы не пугайтесь расстреливать не будут.

Ну да, только исходники зажимать. Видели уже такое в 80-90 прошлого века. Добавки не надо, спасибо.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Клыкастый , 09-Май-12 07:31 
> Ну да, только исходники зажимать. Видели уже такое в 80-90 прошлого века.

Секта Свидетелей BSD. Лично видели как код BSD на всех компах зашифровался и местами превратился в тыкву.


> Добавки не надо, спасибо.

Да вам и без добавки хорошо, с 80-90 прошлого века тащит.

"Завязывать надо с хиромантией, дружок..." (с)


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 10-Май-12 16:43 
> Секта Свидетелей BSD. Лично видели как код BSD на всех компах зашифровался
> и местами превратился в тыкву.

BSDi вполне себе превратился, как и некоторые иные коммерческие форки/клоны/перепевки :)

>> Добавки не надо, спасибо.
> Да вам и без добавки хорошо, с 80-90 прошлого века тащит.

Спасибо, а у нас тут 2012 год на дворе. У нас тут железки 5х5 сантиметров - типа компьютеры уже. Но ваше добро там не работает. Вот вы и тащите, х86 гробины в основном.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Куяврик , 11-Май-12 09:55 
>> Секта Свидетелей BSD. Лично видели как код BSD на всех компах зашифровался
>> и местами превратился в тыкву.
> BSDi вполне себе превратился, как и некоторые иные коммерческие форки/клоны/перепевки :)

Коммерческие Линуксы тоже вполне себе зигибались. И?

> Спасибо, а у нас тут 2012 год на дворе.

А трава с 80-х. Удобно.

> У нас тут железки 5х5 сантиметров - типа компьютеры уже. Но ваше добро там не работает.

Смотря какое смотря где. И кстати, ещё не вечер. Я бы попросил вас подождать и посмотреть позже. Вы же попросите меня подождать, если я спрошу про датацентр, который выкинул блейды и теперь полностью на "железках 5 на 5 типа компьютерах"?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Anonim , 08-Май-12 01:27 
>> на ноутбуке с восьмиядерным процессором Intel Core i7

Фороникс шлет письма из будущего ))


"Сравнение производительности GCC и LLVM-Clang"
Отправлено pavlinux , 08-Май-12 02:49 
Пля, когда Фроникс сделает бенчмарки скорости света в вакууме,
при движении фотонов справа-налево, слева-направо, снизу-вверх и сверху-вниз.

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Серж , 08-Май-12 04:28 
этим займетесь вы в свободное лт работы времени

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 11:10 
Ты предлагаешь форониксу заняться изучением хабловского смещения? Измерение скорости фотонов в зависимости от направления в вакууме (в присутствии гравитационного поля) вовсе не бессмысленное занятие. Просто этим больше астрофизики занимаются, а не айтишники.

"Сравнение производительности GCC и LLVM-Clang"
Отправлено pavlinux , 08-Май-12 18:22 
А чё там изучать, куда дует гравитация туда быстрее и полетит,
да ешё ускорение Кариолиса добавить....   :)

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 19:06 
> да ешё ускорение Кариолиса добавить....   :)

Может, Кориолиса? :)


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Сергей , 09-Май-12 00:33 
От вороньева слова "каррр", поэтому пррравильно Каррриоллисса

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 09-Май-12 02:40 
> От вороньева слова "каррр", поэтому пррравильно Каррриоллисса

А, ну да, павлин каркать любит, не отнять. Иногда даже дельно каркает, но к сожалению - только иногда :(


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 09:33 
На соревнованиях по бегу между США и СССР выиграл американский бегун.
В штатовских газетах пишут "американский бегун пришел к финишу первым".
В советских - "американский бегун пришел к финишу предпоследним".

Вот в сравнении LLVM и GCC все примерно так же звучит, в зависимости чей бегун таки первый пришел к финишу в данный момент.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 11:12 
> На соревнованиях по бегу между США и СССР выиграл американский бегун.
> В штатовских газетах пишут "американский бегун пришел к финишу первым".
> В советских - "американский бегун пришел к финишу предпоследним".

... "американский бегун пришел к финишу первым, а советский - последним"
... "советский бегун пришел к финишу вторым, а американский - предпоследним"


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 12:51 
Я по ссылке увидел только в двух случаях LLVM лучше. причем на крохи (доли процента буквально).

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Сергей , 08-Май-12 15:25 
http://openbenchmarking.org/result/1204215-SU-LLVMCLANG23

"Сравнение производительности GCC и LLVM-Clang"
Отправлено pavlinux , 08-Май-12 18:28 
> http://openbenchmarking.org/result/1204215-SU-LLVMCLANG23

John The Ripper v1.7.9 Test: Blowfish - порадовало: GCC 4.6.3 - 2215 комбинаций в секунду, Шланг - 662 :)

---

Я ж говорю - фроникс гавно, 1 результат в пользу одного,
2-ой в пользу другого, остальные нарисованные в пределах 2%-статистической ошибки.

Я вот не верю, что один и тот же С-код может тормозить иль наоборот разогнан на 335% !!!
Это надо очень постараться, чтоб так тормознуть - напихать отладочной инфы,
циклов, периодически сохранять дампы и пустить все это дело через трассировщик.

Но фрониксу пох...ю, они добиваются не правды, а эффекта.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 19:15 
> Я вот не верю, что один и тот же С-код может тормозить
> иль наоборот разогнан на 335% !!!

Вероятно оптимизатор лопухнулся и где-то в горячем месте сгенерил совсем уж гогнокод по сравнению с другим, или может асм не поюзался, или еще что-то типа того. В горячих местах лишние несколько команд спокойно могут все тормознуть в разы, если там всего несколько команд и было.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 19:12 
> Я по ссылке увидел только в двух случаях LLVM лучше. причем на
> крохи (доли процента буквально).

Ну так про бегуна все верно написали. Если вы бcдун то понятное дело - эпплу надо подлизать. Если линуксоид - эппл вам не друг и не товарищ, соответственно :)



"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 15:13 
> Ресурс Phoronix провёл (http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc)
> тестирование производительности приложений, собранных при помощи компиляторов GCC 4.6.3,
> GCC 4.7.0, LLVM-Clang 3.0, LLVM-Clang 3.1 SVN и Open64 5.0 (http://www.opennet.me/opennews/art.shtml?num=32275)

забавно. но никто не заметил что gcc 4.7 сливает не только gcc-4.6.3 но и clang.
вот такое оно будущее gcc - постоянные регрессии и тормоза.



"Сравнение производительности GCC и LLVM-Clang"
Отправлено Куяврик , 08-Май-12 16:38 
> забавно. но никто не заметил что gcc 4.7 сливает не только gcc-4.6.3 но и clang.
> вот такое оно будущее gcc - постоянные регрессии и тормоза.

Не надо скоропалительных выводов. ни относительно clang, Ни относительно gcc 4.7.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено arisu , 08-Май-12 16:42 
нет, тормоза уходят пользоваться шлангом.

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 19:13 
> вот такое оно будущее gcc - постоянные регрессии и тормоза.

Таненбаум, залогиньтесь :)


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 08-Май-12 22:33 
Забавно, особенно если учесть желание GCC-шников прийти к более модульной системе как в LLVM и они предупреждали о падении скорости в будущих выпусках.

"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 09-Май-12 01:48 
> вот такое оно будущее gcc - постоянные регрессии и тормоза.

Ичсх, регрессию в шланг-svn (не совсем) благородный дон почему-то предпочел не заметить :). "Если факты не подтверждают теорию - от них нужно избавиться!"


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 09-Май-12 09:01 
>> вот такое оно будущее gcc - постоянные регрессии и тормоза.
> Ичсх, регрессию в шланг-svn (не совсем) благородный дон почему-то предпочел не заметить
> :). "Если факты не подтверждают теорию - от них нужно избавиться!"

svn это не релиз. а сравнение gcc 4.6.3 и 4.7.0 это сравнение 2х релизов :)
вот если бы в релизах у clang были регрессии - тогда повод для кипиша, хотя нет - это только GNU с их цацкой GCC могут выпускать регрессии в релизах и называть фичами.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 10-Май-12 16:58 
> svn это не релиз.

И что? Если оптимизатор перепахали - совершенно нормально что он в одних случаях может стать лучше а в других хуже. Идеальная эвристика - это вообще нечто сферическое и в вакууме. У процов еще и архитектуру перепахивают, так что то что было хорошо несколько лет назад может быть плохо вот прям ща, и наоборот.

> а сравнение gcc 4.6.3 и 4.7.0 это сравнение 2х релизов :)

Так надо всестороннее сравнение делать - на всех архитектурах, в куче разных задач. Разработчики ж не ставят специальной цели все сломать. Просто выиграв в одном можно проиграть в другом. Чего ради утверждается что у шланга так не будет - я не понял, в svn как раз именно такое и наблюдается вообще.

> вот если бы в релизах у clang были регрессии

Хотите сказать что их не было, нет и не будет? А вы точно это проверяли? На всех архитектурах и всех мыслимых типах программ?

> - тогда повод для кипиша, хотя нет - это только GNU с их цацкой
> GCC могут выпускать регрессии в релизах и называть фичами.

Ну да, ну да, а infernal compiler error в релизе - это как называть? Фичой?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено iZEN , 08-Май-12 21:20 
Поздравляю всех пользователей новых технологий — LLVM/Clang уже выглядит бодрячком на фоне старпёров и больше не просирает полимеры почём зря.

(Сам использую Clang 3.0 для компиляции и сборки системы FreeBSD 9-STABLE и большей части установленных программ. Недавно портированный Chromium стал собираться системным Clang'ом.)


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 09-Май-12 01:50 
> Поздравляю всех пользователей новых технологий

Это говорит бсдшник? Ну и как там поживают твои атевые дрова ископаемой версии? А HD 7xxx у вас когда заработает? Если уж мы о новых технологиях - у амд их есть. В новом дизайне GPU еще более заточенном на вычисления.


"Сравнение производительности GCC и LLVM-Clang"
Отправлено iZEN , 09-Май-12 10:15 
>> Поздравляю всех пользователей новых технологий
> Это говорит бсдшник? Ну и как там поживают твои атевые дрова ископаемой версии?

Отлично поживают. AMD 785G показывает Full HD h.264 видео без тормозов на HP LP2475w. Летом планирую апгрейд на AMD 880G и FX-6120. У меня будет 16 ГБ ОЗУ в домашней машинке (что ускорит работу ZFS). Когда диски подешевеют, буду мигрировать RAID-Z на пул большего объёма.

> А HD 7xxx у вас когда заработает?

Дома в компьютерные игры не играю.

> Если уж мы о новых технологиях - у амд их есть. В новом дизайне GPU еще более заточенном на вычисления.

И что это мне даст?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено Аноним , 10-Май-12 17:22 
> Отлично поживают. AMD 785G показывает Full HD h.264 видео без тормозов

А 3D ускорение нормально работает? А то я следил за развитием этого драйвера и прогресс с момента доKMSной эры - весьма доставляет, скорость выросла в разы, корректность реализации opengl подтянули весьма даже. А в идеале хорошо бы еще и ускорение декодирования видео + opencl (в том числе и для акселерирования на нем произвольных кодеков, постпроцессинга и прочих фильтров/эффектов).

>  на HP LP2475w.

Это что? Монитор? Тормозящий монитор - это был бы номер!

> Летом планирую апгрейд на AMD 880G и FX-6120.

А в чем прикол втыкать "топовый" проц в удешевленный чипсет с интегрированной графикой? Это наверное специально чтобы как можно глупее тормознуть крутой проц (и без того упирающийся в RAM) еще и дополнительными поползновениями GPU претендующего на системную оперативку, да? Сбалансированная системная конфигурация "от изена" :D

> У меня будет 16 ГБ ОЗУ в домашней машинке (что ускорит работу ZFS).
> Когда диски подешевеют, буду мигрировать RAID-Z на пул большего объёма.

Ну да, а то что в интеграшке бандвиз оперативы делится на проц и GPU тебя видимо не смущает :)

>> А HD 7xxx у вас когда заработает?
> Дома в компьютерные игры не играю.

Да с тобой никакие игры не нужны - ты и так тонну лулзов генеришь. Например зачем-то покупая топовый проц при интеграшечной видяхе. Ты никогда не думал почему имеет смысл покупать комплектуху более-менее одного ценового диапазона, правда? :)

>> Если уж мы о новых технологиях - у амд их есть. В новом дизайне GPU еще более заточенном на вычисления.
> И что это мне даст?

Тебе? Ничего - у тебя этот драйвер будет фиг знает когда. Мне - скоростные вычисления. Которым применений - навалом. По мере внедрения фичи в открытых дровах оно пойдет в массы, т.к. у разработчиков будет как раз "по дефолту" в системах :)


"Сравнение производительности GCC и LLVM-Clang"
Отправлено iZEN , 10-Май-12 23:45 
>> Отлично поживают. AMD 785G показывает Full HD h.264 видео без тормозов
> А 3D ускорение нормально работает? А то я следил за развитием этого
> драйвера и прогресс с момента доKMSной эры - весьма доставляет, скорость
> выросла в разы, корректность реализации opengl подтянули весьма даже. А в
> идеале хорошо бы еще и ускорение декодирования видео + opencl (в
> том числе и для акселерирования на нем произвольных кодеков, постпроцессинга и
> прочих фильтров/эффектов).
>>  на HP LP2475w.
> Это что? Монитор? Тормозящий монитор - это был бы номер!

Это монитор бизнес-класса с матрицей S-IPS разрешением 1920x1200 от Hewlett Packard. Имеет несколько цифровых и аналоговых интерфейсов. Дополнительно можно приобрести фирменные пристёгивающиеся стереоколонки с регулятором громкости и двумя выходами на наушники.
Обсуждение монитора: http://forum.ixbt.com/topic.cgi?id=28:23370

>> Летом планирую апгрейд на AMD 880G и FX-6120.
> А в чем прикол втыкать "топовый" проц

Сразу ошибка. FX-6120 — это "середнячок". Топовый у AMD пока что FX-8150. ;)

> в удешевленный чипсет с интегрированной графикой?

Лучший чипсет с интегрированной графикой — только в полноразмерных ATX-материнках, а у меня корпус Micro-ATX.

> Это наверное специально чтобы как можно глупее тормознуть крутой проц
> (и без того упирающийся в RAM) еще и дополнительными поползновениями GPU
> претендующего на системную оперативку, да? Сбалансированная системная конфигурация "от
> изена" :D

Главный принцип в сборке домашнего компьютера — ТИШИНА и отсуствие завывающих вентиляторов.
А процессор этого уровня нужен для быстрой компиляции, вот и всё.

>> У меня будет 16 ГБ ОЗУ в домашней машинке (что ускорит работу ZFS).
>> Когда диски подешевеют, буду мигрировать RAID-Z на пул большего объёма.
> Ну да, а то что в интеграшке бандвиз оперативы делится на проц и GPU тебя видимо не смущает :)

Не смущает. Хватает.

>>> А HD 7xxx у вас когда заработает?
>> Дома в компьютерные игры не играю.
> Да с тобой никакие игры не нужны - ты и так тонну
> лулзов генеришь. Например зачем-то покупая топовый проц при интеграшечной видяхе. Ты
> никогда не думал почему имеет смысл покупать комплектуху более-менее одного ценового
> диапазона, правда? :)

Я думал о многом. А ещё я думаю о сбалансированности системы под те или иные задачи. Пока что на видеокартах играются только игры, а обычные инженерные CAD-системы до сих пор не осилили 3D-акселерацию средствами видеокарт, обходятся расчётами моделей на CPU. Компиляция — прерогатива CPU, опять же.

>>> Если уж мы о новых технологиях - у амд их есть. В новом дизайне GPU еще более заточенном на вычисления.
>> И что это мне даст?
> Тебе? Ничего - у тебя этот драйвер будет фиг знает когда. Мне
> - скоростные вычисления. Которым применений - навалом. По мере внедрения фичи
> в открытых дровах оно пойдет в массы, т.к. у разработчиков будет
> как раз "по дефолту" в системах :)

А чем ты сейчас обходишься для своих расчётов, если не секрет? В чём заключается полезность использования GPU лично для тебя?


"Сравнение производительности GCC и LLVM-Clang"
Отправлено iZEN , 09-Май-12 23:47 
> Если уж мы о новых технологиях - у амд их есть. В новом дизайне GPU еще более заточенном на вычисления.

NVIDIA тоже не отстаёт — "09.05.2012 20:52  NVIDIA передала CUDA Compiler в руки сообщества LLVM" http://www.opennet.me/opennews/art.shtml?num=33800