форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Сравнение производительности GCC и LLVM-Clang"	+/–
Сообщение от opennews (??) on 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.dev/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.dev/opennews/art.shtml?num=33789
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Сравнение производительности GCC и LLVM-Clang"	+9 +/–
Сообщение от Аноним (??) on 07-Май-12, 23:59
допилят еще clang
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Сравнение производительности GCC и LLVM-Clang"	+16 +/–
	Сообщение от paulus (ok) on 08-Май-12, 00:09
	да пусть пилят, только и GCC на месте не стоит...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	19. "Сравнение производительности GCC и LLVM-Clang"	+4 +/–
	Сообщение от архитектор on 08-Май-12, 06:54
	> да пусть пилят, только и GCC на месте не стоит... Нужно уметь видеть не только скорость движения, и уж тем более не только сам факт наличия хоть какого-то движения. Нужно уметь видеть траекторию пути. А с этим у большинства очень туго. Продуманность архитектуры llvm/clang против бардака gcc. Это как набирание скорости clang'ом по шоссе, пусть даже извилистому - против стремления gcc ломиться напрямую и через лес. Пусть даже пока и выше, по инерции, у gcc эта скорость "не стояния на месте". Надо видеть качество, а не только количество. Не в обиду gcc - он все-таки был один из пионеров в области мультиязыковых компиляторов. Просто такова история - следующие учатся на ошибках предыдущих.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	25. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от MiG on 08-Май-12, 11:02
	> Продуманность архитектуры llvm/clang против бардака gcc. > ..... > Надо видеть качество, а не только количество. Когда clang станет поддерживать такое же количество аппаратных и программных платформ (со всеми присущими им косяками и фичами) как и GCC вот тогда и будет уместно сравнивать их архитектуру, производительность, бардак и т.п..
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	28. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от архитектор on 08-Май-12, 11:26
	>> Продуманность архитектуры llvm/clang против бардака gcc. >> ..... >> Надо видеть качество, а не только количество. > > Когда clang станет поддерживать такое же количество аппаратных и программных платформ (со всеми присущими им косяками и фичами) как и GCC вот тогда и будет уместно сравнивать их архитектуру, производительность, бардак и т.п.. Вот очередное "чудо" мышления. Как не пытаются думать о качестве, все равно у них получается только в плоскости количества, до этого была "скорость", теперь "количество платформ". На этот раз оказывается, что качество архитектуры определяется якобы _количеством_ поддерживаемых платформ. То есть, значит, именно так: стоит перенести на как можно большее количество платформ, и качество возникнет само собой. А я-то, наивный, думал, что чем качественнее проработана архитектура, тем легче будет переносить на разные платформы, а не наоборот. А оно ведь вон как оказывается. ))))
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	32. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от filosofem (ok) on 08-Май-12, 12:33
	>Вот очередное "чудо" мышления. >Как не пытаются думать о качестве, все равно у них получается только в плоскости количества, до этого была "скорость", теперь "количество платформ". Вы, любезный, сильно не обижайтесь, но это у вас ГСМ. Ваше "качество" и "архитектура" нужно как-то спроецировать в количественные характеристики, хотя бы как это сделано в сабже. Без этого ваши теоретизирования о "качестве" не более обоснованы, чем испускание газов в небольшой водоем. >А я-то, наивный, думал, что чем качественнее проработана архитектура, тем легче будет переносить на разные платформы, а не наоборот. Вам вот что пытаются сказать: Мы имеем две программы одна обладает функциями A, B, ... ,W, а вторая только A с оговорками и при этом работает немного быстрее, но готовит более тормозной код. Это ситуация на данный момент времени. Вполне логично предположить, что, обрастая функционалом, программа будет работать только медленнее и количество граблей и костылей в ней будет увеличиваться.   Так что пилите и портируйте ваш ЛЛВМ-Шланг. Когда допилите потестируем и сравним и сделамем вывод, какая архитектура молодежнее и качественнее. Сейчас это несколько преждевременно делать.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	43. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от архитектор on 08-Май-12, 14:48
	> Вы, любезный, сильно не обижайтесь, но это у вас ГСМ. Ваше "качество" и "архитектура" нужно как-то спроецировать в количественные характеристики, хотя бы как это сделано в сабже. Без этого ваши теоретизирования о "качестве" не более обоснованы, чем испускание газов в небольшой водоем. Это у вас стереотипы марксистской диалектики. Не любое количество переходит в качество. Не любое качество выражается количественно. Во времена расцвета компьютерной математики крайне полезно знать, что числовые системы (эти ваши количества) - это всего лишь очень частный случай из всех возможных математических и вообще концептуальных систем. Так что качество вообще может выражаться без каких либо количеств. К.Маркс отдыхает. Хотя, если для вас это всего лишь голые теории, спите спокойно дальше. > Вам вот что пытаются сказать: Мы имеем две программы одна обладает функциями A, B, ... ,W, а вторая только A с оговорками и при этом работает немного быстрее, но готовит более тормозной код. Это ситуация на данный момент времени. Вполне логично предположить, что, обрастая функционалом, программа будет работать только медленнее и количество граблей и костылей в ней будет увеличиваться. Опять таки, смотря как именно она будет обрастать функционалом. Я уже сказал, что вы видите лишь наличие движения, но не видите траектории. > Так что пилите и портируйте ваш ЛЛВМ-Шланг. Когда допилите потестируем и сравним и сделамем вывод, какая архитектура молодежнее и качественнее. Сейчас это несколько преждевременно делать. Ну оно конечно продолжает "пилиться", как и весь остальной софт. Только уже давно протестировано и реально используется. Если вы проспали, ничем помочь не могу. Ждите, когда появятся ваши любимые "количества", без которых вы никак не можете.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	66. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от filosofem (ok) on 08-Май-12, 17:33
	>Это у вас стереотипы марксистской диалектики. Сами начали. Я на методологическую ошибку указал и не собирался поддерживать религиозную демагогию про количесва, качества и их переходы и непереходы. >Так что качество вообще может выражаться без каких либо количеств. К.Маркс отдыхает. Выражайте сколько угодно. Вы же утверждаете, что одна архитектура качественнее, продуманней, эффективнее и правильнее другой, а это уже не имеет смысла без количественного сравнения. >Опять таки, смотря как именно она будет обрастать функционалом. >Я уже сказал, что вы видите лишь наличие движения, но не видите траектории. И тут конечно следует пояснить чем одна траектория настолько принципиально лучше другой, кроме лицензии. И обосновать почему все должны обязательно ходить вашей траекторией, а не выбирать самостоятельно какая им нужнее.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	74. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от архитектор on 08-Май-12, 19:00
	>>Это у вас стереотипы марксистской диалектики. > > Сами начали. Ничего подобного. Читайте внимательно посты. На что именно я ответил в первом посте, и как именно ответил. И как отвечал далее. >и не собирался поддерживать религиозную демагогию про количесва, качества и их переходы и непереходы. Назвались груздем - полезайте в кузов. И дело вовсе не в вашем нике. Вот где вы начали: <цитата>Ваше "качество" и "архитектура" нужно как-то спроецировать в количественные характеристики, хотя бы как это сделано в сабже.</цитата> И не надо на меня стрелки переводить. > Я на методологическую ошибку указал Ваш анализ якобы методологических ошибок базировался на следующем вашем утверждении. > Вам вот что пытаются сказать: Мы имеем две программы одна обладает функциями A, B, ... ,W, а вторая только A с оговорками и при этом работает немного быстрее, но готовит более тормозной код. Это ситуация на данный момент времени. Вполне логично предположить, что, обрастая функционалом, программа будет работать только медленнее и количество граблей и костылей в ней будет увеличиваться. >> >>Опять таки, смотря как именно она будет обрастать функционалом. Ну я вам уже ответил, это зависит от того, как именно будет изменяться функционал. И никак не логично предполагать из поставленных вами условий, что будет именно такое следствие. Основная ваша ошибка здесь, что вы безусловно постулируете, что главным критерием является якобы опять-таки скорость работы. Правильность - безусловно, но это опять-таки не количественная характеристика, и она не определяется тупо количеством ошибок. Ибо что есть ошибка? >>Так что качество вообще может выражаться без каких либо количеств. К.Маркс отдыхает. > > Выражайте сколько угодно. Вы же утверждаете, что одна архитектура качественнее, продуманней, эффективнее и правильнее другой, а это уже не имеет смысла без количественного сравнения. Вот опять нет! Читайте внимательно посты. Вам просто кажется, что я так говорил, потому что вы только так умеете мыслить, и считаете ваш образ мышления единственно возможным. Единственное место, где я позволил себе сравнить две архитектуры, была моя фраза:   - Продуманность архитектуры llvm/clang против бардака gcc. - здесь нет никаких количественных сравнений, если будете утверждать, что якобы есть, то вы просто ничего не понимаете в проектировании софта. Дальше моя фраза:   - Пусть даже пока и выше, по инерции, у gcc эта скорость "не стояния на месте". - здесь лишь допущение позиции оппонента, рассуждение от противного. Единственное место, где я допустил вообще сравнительную степень прилагательных:   - ...чем качественнее проработана архитектура, тем легче будет переносить на разные платформы, а не наоборот. - но здесь я не сравнивал архитектуры, как вы утверждаете. И уж нигде не было слов "эффективнее и правильнее", как вы утверждаете. И качество я нигде не сравнивал. Я лишь говорил:   - Надо видеть качество, а не только количество. И про "траектории", см. ниже. Далее, из следующих и прочих моих фраз:   - Не любое количество переходит в качество.   - Не любое качество выражается количественно. никак не следует, что качество вообще никогда не может определяться количеством, надо лишь знать, когда именно. Но вы этого не знаете, если утверждаете: >> <...> а это уже не имеет смысла без количественного сравнения. >> Ваше "качество" и "архитектура" нужно как-то спроецировать в количественные характеристики, хотя бы как это сделано в сабже. То есть вы утверждаете, что якобы всегда нужны количественные оценки. А я лишь утверждаю, что не всегда, и даже не нужно в подавляющем количестве случаев. Так что у меня все логично. >>Я уже сказал, что вы видите лишь наличие движения, но не видите траектории. > > И тут конечно следует пояснить чем одна траектория настолько принципиально лучше другой, кроме лицензии. И обосновать почему все должны обязательно ходить вашей траекторией, а не выбирать самостоятельно какая им нужнее. Ну видите, вы опять в плоскости лучше-хуже. Вы просто не умеете по-другому. И мне пытаетесь это приписывать, хотя я говорю совсем не так. Почему это по-вашему следует пояснять, чем траектории лучше или хуже? Видимо вам не известно, что разные траектории ведут _через_ разные и _в_ разные места. И здесь снова нет никаких количественных сравнений. ----------------- Будете утверждать, что все это якобы теории и демагогия? Как вам угодно. Только все эти теории успешно "прошиваются" в системы искусственного интеллекта. Но вы лучше продолжайте дальше спать, так вам будет спокойнее. P.S. Видите, какую злую шутку играет с вами ваш образ мышления. Вам кажется, что все люди говорят и думают так же, как вы, даже если ничего подобного они не говорили. P.P.S. Такой подробный анализ я сделал в виде исключения, исключительно "ради вас". У вас хотя бы получается хоть немного думать. Тем же "грамотеям", кто вообще думать не в состоянии, я ответил по-проще.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	92. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от filosofem (ok) on 08-Май-12, 19:41
	>Назвались груздем - полезайте в кузов. И дело вовсе не в вашем нике. Вот где вы начали <цитата>Ваше "качество" и "архитектура" нужно как-то спроецировать в количественные характеристики, хотя бы как это сделано в сабже.</цитата> И не надо на меня стрелки переводить. Почему не надо, я же вам отвечал на всши рассуждения про качества. Если хотите религии, пожалуйста: от количество вы никуда не убежите, обладание каким-либо качеством тоже является количественной характеристикой, количество может равняться 0, а может единице. =) >Ваш анализ якобы методологических ошибок базировался на следующем вашем утверждении. Методологическая ошибка в том, что вы хотите провести количественное сравнение без количественных шкал. Именно количественное. Если вы утверждаете, что одна из архитектур предпочтительнее, это количественное сравнение. Без количества можно говорить только об идентичности или не идентичности двух архитектур или с некоторой натяжкой об их подобии. С другой стороны если вы утверждаете, что вы этого не утверждали и архитектура Шланге не лучше, не молодежнее, не православнее, не эффективнее и не продуманнее ГЦЦ, то о чем вы вообще спорите? =)
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	94. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от архитектор on 08-Май-12, 20:17
	>>Назвались груздем - полезайте в кузов. И дело вовсе не в вашем нике. Вот где вы начали <цитата>Ваше "качество" и "архитектура" нужно как-то спроецировать в количественные характеристики, хотя бы как это сделано в сабже.</цитата> И не надо на меня стрелки переводить. > > Почему не надо, я же вам отвечал на всши рассуждения про качества. А я отвечал на рассуждения про количества, еще до вас. Почему вам можно отвечать, а у меня якобы сразу демагогия, как только я вам возразил. > Если хотите религии, пожалуйста: от количество вы никуда не убежите, Из того, что для вас математика и информатика - религия, а сама математика для вас состоит исключительно из численных систем, следует, что у вас ярко выраженный гуманитарный склад мышления, но вы упорно встреваете в технические области. > обладание каким-либо качеством тоже является количественной характеристикой, количество может равняться 0, а может единице. =) Я уже сказал, что я знаю, что это не так. Хотя ваше право считать по-другому. Оно может вообще не выражаться числами. Просто вы видимо, кроме чисел, других информационных и математических систем не знаете. > Методологическая ошибка в том, что вы хотите провести количественное сравнение без количественных шкал. Именно количественное. Если вы утверждаете, что одна из архитектур предпочтительнее, это количественное сравнение. С каких это пор "предпочтение" обязано выражаться исключительно количественно? И еще раз, я нигде не утверждал того, что вы мне здесь приписываете. Свои высказывания я подробно разобрал в предыдущем посте, повторяться не буду. > Без количества можно говорить только об идентичности или не идентичности двух архитектур или с некоторой натяжкой об их подобии. Очередная глупость и невежество. Просто догма. И еще будете рассказывать мне про "религию". > С другой стороны если вы утверждаете, что вы этого не утверждали и архитектура Шланге не лучше, не молодежнее, не православнее, не эффективнее и не продуманнее ГЦЦ, то о чем вы вообще спорите? =) Кажется, до вас начало доходить, что я мог утверждать что-то другое. Сто раз уже сказал, о чем. Для тех, кто в бункере повторяю: я говорил о том, что "нужно смотреть не только на количество, но и на качество". Из этого никак не следует то, что вы перечислили. Я уже сказал, что вы просто не можете мыслить иначе, поэтому вам кажется, что по-другому якобы невозможно.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	96. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от filosofem (ok) on 08-Май-12, 20:45
	>>> С другой стороны если вы утверждаете, что вы этого не утверждали и архитектура Шланге не лучше, не молодежнее, не православнее, не эффективнее и не продуманнее ГЦЦ, то о чем вы вообще спорите? =) >Кажется, до вас начало доходить, что я мог утверждать что-то другое. Отрекаетесь от идейного превосходства продуманности и эффективности архитектуры Шланге, уже прогресс. Продолжаем. >Сто раз уже сказал, о чем. Для тех, кто в бункере повторяю: я говорил о том, что "нужно смотреть не только на количество, но и на качество". Эта фраза ни о чем, вы это понимаете? Вы хотите сказать, что архитектура шланге обладает неким "качеством", которым не обладает гцц, но при этом она не лучше не православнее, не эффективнее и не продуманнее. Так? =)))) Кстати вы не путаете качество в понимании религии Иисуса^W Маркса и качество в понимании отдела контроля качества? Они никак не связаны если что.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	125. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от архитектор on 09-Май-12, 04:28
	>>Кажется, до вас начало доходить, что я мог утверждать что-то другое. > > Отрекаетесь от идейного превосходства продуманности и эффективности архитектуры Шланге, уже прогресс. Зачем мне отрекаться, от того с чем я и не был никак связан. Читайте внимательно, что я писал, и на какие высказывания я отвечал. А пока вы продолжаете заниматься приписками. Я лишь с самого начала заявлял, что глупо судить об идейном превосходстве по скорости работы, количеству инсталляций, клоичеству поддерживаемых платформ, и прочим "количествам". Как у вас тут получается "идея превосходства clang", и почему вы не видите других вариантов - это вы сами разбирайтесь. См. ниже о моей единственной фразе касательно clang. > Продолжаем. Вам следовало бы сначала разобраться со своими старыми ошибками, прежде чем продолжать делать новые. Тоже мне, "филосов". >>Сто раз уже сказал, о чем. Для тех, кто в бункере повторяю: я говорил о том, что "нужно смотреть не только на количество, но и на качество". > > Эта фраза ни о чем, вы это понимаете? Если она для вас "ни о чем", то это не значит, что она вообще такова. И вы, и многие другие ораторы, никак не можете выйти из плоскости количественных оценок. Так что вышеуказанная моя фраза в этом контексте очень даже "о чем". И еще. На ваш вопрос из предыдущего поста типа, "о чем же вы тогда спорите, если не о превосходстве clang". Так вот об этом как раз. Что вы никак не можете выйти в своем мышлении за пределы численных систем и всяких там "количеств". С самого начала об этом и говорю, еще до вашего появления. А вы все "о чем", да "о чем". Не видите, что у вас "под носом". > Вы хотите сказать, что архитектура шланге обладает неким "качеством", которым не обладает гцц, но при этом она не лучше не православнее, не эффективнее и не продуманнее. Так? =)))) И не только одним "качеством". Просто остановились на одном. Но при чем здесь "православие"? И при чем здесь "лучше-хуже"? Я сказал так: "Продуманность архитектуры llvm/clang против бардака gcc." Естественно, эта мысль была сильно упрощена с учетом аудитории, для которой она говорилась, и в целях краткости. Но суть от этого не меняется. Просто с более строгой точки зрения следует сравнить более детально конкретные компоненты и подсистемы обсуждаемых творений. И в gcc тоже много чего "продумано". Просто чисто исторически, в clang "продуманы" системы, которые в gcc создавались хаотично. Это нормально, когда учатся на ошибках своих предшественников. Я уже обозначил эту мысль в самом первом своем посте. Однако по-прежнему даже в этом случае какие-либо количественные оценки потребуются не часто. При чем здесь "лучше-хуже", "больше-меньше"? А больше про clang я ничего не говорил. Все остальное - плод вашего воображения под воздействием эмоций, а не разума. Эффективность тоже не обязана выражаться количественно. А уж откуда у вас берутся такие словечки, как "правостлавность" и "молодежность". Только из гуманитарного склада вашего мышления. Но вы хотя бы попытались использовать разум. Остальные вообще сразу вошли в эмоциональный ступор, как только речь зашла о чем-то другом, кроме "количеств" и "скоростей". > Кстати вы не путаете качество в понимании религии Иисуса^W Маркса и качество в понимании отдела контроля качества? Они никак не связаны если что. Похоже это вы совсем запутались, и уже не знаете, что с чем связать.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	29. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от Аноним (??) on 08-Май-12, 11:46
	>Продуманность архитектуры llvm/clang против бардака gcc. Ахаха! Аналитик с ЛОРа, не иначе. Не видел кода не там, ни там, а кукарекает еще об архитектурах. llvm выгодна только эплу, чтоб код скрывать. Вот и все различие.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	31. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от _yurkis_ on 08-Май-12, 12:23
	>>Продуманность архитектуры llvm/clang против бардака gcc. >Ахаха! Аналитик с ЛОРа, не иначе. Не видел кода не там, ни там, а кукарекает еще об архитектурах. Я код видел. Могу подтвердить слова этого товарища. А Вы? >llvm выгодна только эплу, чтоб код скрывать. Вот и все различие. Вот это умозаключение как раз спалило Вас, уважаемый. На ЛОРе такого понабрались? clang нужен как минимум: 1. FreeBSD- ну понятно... 2. Куче коммерческих контор (Adobe там, еще кто- то) 3. Гуглю (AddressSanitizer для тестирования хрома, если чего). 4. Чем там в открытых дровах видеокарт шейдеры, OpenCL и т.п. компилируется? 5. Очень много кому еще Кстате, об AddressSanitizer, статическом анализаторе LLVM и еще некоторых плюшках настоятельно советую погуглить. Может тогда Вы отбросите религию и LLVM будет полезна и Вам тоже.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	39. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от Куяврик on 08-Май-12, 14:08
	Не всем дано вот так просто отбросить религию :)
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	47. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от kurokaze (ok) on 08-Май-12, 15:21
	Тут в топике и религиозных фанатиков clang-а хватает. Но они себя конечно такими не считают нибожеж мой
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	59. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от Куяврик on 08-Май-12, 16:43
	> Тут в топике и религиозных фанатиков clang-а хватает. Но они себя конечно такими не считают нибожеж мой Хватает для чего? clang пилится, пилится активно, имеет некоторые успехи и в общем явно помлаже, чем гцц. Если люди считают, что переспектива - есть, это что - фанатизм? Если не устраивает лицензия ГНУ и люди рады, что есть альтернатива, это что - фанатизм? Если вы не об этих двух случаях, то о чём?
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	61. "Сравнение производительности GCC и LLVM-Clang"	–2 +/–
	Сообщение от arisu (ok) on 08-Май-12, 16:44
	> Если не устраивает лицензия ГНУ вот это-то и подозрительно.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	62. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от Куяврик on 08-Май-12, 16:56
	> вот это-то и подозрительно. Это очень подозрительная подозрительность. http://www.gnu.org/licenses/license-list.html Смотрим список свободных лицензий и видим что их там сильно больше одной, и совсем не все начинаются с GPL*. Ну дальше я могу по десятому разу рассказать что код BSD был, есть и будет открытым, но как и предыдущие разы фанатизм твой будет непокобелим :)
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	64. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от arisu (ok) on 08-Май-12, 17:12
	знаешь, что это мне напоминает? примерно такой диалог: — давай начинать дело! — давай, только договор составим. — да ты чо, зачем нам договор, мы же друзья! — то есть, ты меня обмануть хочешь? — нет, конечно! — тогда давай договор. — но мы же друзья! (это я не про наш диалог, если кто не понял) если не собираются делать проприетарный закрытый форк — то почему не GPL? «мы же друзья»?
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	68. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от Куяврик on 08-Май-12, 17:49
	> если не собираются делать проприетарный закрытый форк — то почему не GPL? ты сейчас вот так абстрактно говоришь? если да - то в принципе да, почему бы и не gpl. если конкретно - то и конкретно надо смотреть. возможно, используются наработки, несовместимые с GPL. возможно, есть исторические причины. опять таки вопрос - мы будем позволять брать наш открытый код, чтобы _на его основе_, кто-то добавив _свой_ код мог этот код не публиковать? ты против. мне например, пофиг. мне не жалко. на наш проект это никак не повлияет. так что, кроме "взять и закрыть" есть множество нюансов.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	87. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 08-Май-12, 19:23
	> возможно, есть исторические причины. Да, у эппла есть исторические причины: они как-то так исторически любят зажимать все что зажимается, а выбрасывают на публику только наименее ценные объедки.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	101. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от _yurkis_ on 08-Май-12, 21:44
	>> возможно, есть исторические причины. > Да, у эппла есть исторические причины: они как-то так исторически любят зажимать > все что зажимается, а выбрасывают на публику только наименее ценные объедки. Вас это беспокоит? Кто должен решать что Apple делать со СВОИМ кодом?
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	117. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 09-Май-12, 01:40
	> Вас это беспокоит? Кто должен решать что Apple делать со СВОИМ кодом? Да, при принятии решения закладываться ли мне на тул или нет - меня очень даже беспокоит: будет потом кидалово так что мне придется самому разгребать свои проблемы, или же на апстрим можно положиться. На FSF я как-то охотнее положусь чем на эппл. А они пусть там решают что им делать с их кодом наздоровьице.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	138. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 09-Май-12, 11:32
	>> Вас это беспокоит? Кто должен решать что Apple делать со СВОИМ кодом? > Да, при принятии решения закладываться ли мне на тул или нет - > меня очень даже беспокоит: будет потом кидалово так что мне придется > самому разгребать свои проблемы, или же на апстрим можно положиться. На > FSF я как-то охотнее положусь чем на эппл. А они пусть > там решают что им делать с их кодом наздоровьице. ну да FSF один раз кинул всех - начав присваивать себе код, кинул еще раз когда DWG библиотеку отказался отпустить под LGPL - хотя разработчики это просили, кинет тебя и третий раз и будет за тебя решать как поступать с твоей работой. Но ты хавай что дают - хавай. И свято верь что все будет как есть. В то же время apple придерживается той лицензии на которой взяла себе код - и патчи для Object-C все так же доступны на сайте apple под оригинальной GPL v2. Не больше не меньше - ровно под той лиценизией под которой взяли. Хотя да, сейчас это не надо - проще вложиться в Clang - который не будет творить безобразий с лицензированием, как их творил FSF.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	141. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от arisu (ok) on 09-Май-12, 15:03
	какие вы смешные, роботы.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	179. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 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. Вы ж не сомневаетесь что девтим который содержит только эппл может и будет делать изменения удобные эпплу даже если они все ломают нахрен у всех остальных? :)
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	199. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 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 что бы указывать и требовать у авторов выбирать только "нужную" им лицензию?
	Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

	201. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от arisu (ok) on 10-Май-12, 19:00
	> негодуют многие GPL v2 лицензированые САПР. а не надо было читерить, вот и всё. как именно использовать GPL — в ней написано. если кто-то посчитал, что хочет по-другому — на здоровье, но пусть не вякает: поддерживать читы и воркэраунды FSF не обязывалось. > так почему FSF начинает требовать чтобы apple перелицензировало под GPL v3 код > который они написали под GPL v2? чтобы включить его в состав gcc и поддерживать. и не «требовали» а «предложили». огрызок не захотел. товарищи из gcc пожали плечами и сказали, что ССЗБ.
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	210. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 11-Май-12, 14:01
	> а не надо было читерить, вот и всё. как именно использовать GPL — в ней написано. если кто-то посчитал, что хочет по-другому — на здоровье, но пусть не вякает: поддерживать читы и воркэраунды FSF не обязывалось. Использовать GPL v2 only - это читерство? какие вы глупые вьюноша. Поддерживать сексуальные фантазии FSF - что они там придумают в новых версиях - это не логично. Так же как и навязывать пользователям библиотеки какие-то доп условия. Вот люди пожали плечами - и linux world остался без сапра который читает DWG. собственно кто проиграл? только ваш убогий FSF & linux world. > чтобы включить его в состав gcc и поддерживать. и не «требовали» а «предложили». огрызок не захотел. товарищи из gcc пожали плечами и сказали, что ССЗБ. ты старательно забываешь - что именно требовали.
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

	106. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от arisu (ok) on 08-Май-12, 22:03
	> ты сейчас вот так абстрактно говоришь? нет, я сейчас конкретно говорю. > мне например, пофиг. раз пофиг — то почему не GPL? если тебе *действительно* пофиг.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	129. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Клыкастый (ok) on 09-Май-12, 07:35
	>> ты сейчас вот так абстрактно говоришь? > нет, я сейчас конкретно говорю. Конкретно какой проект ты имеешь в виду? >> мне например, пофиг. > раз пофиг — то почему не GPL? если тебе *действительно* пофиг. Ещё раз: мне пофиг, что будут делать с кодом те, кто его возьмут за основу. Возможно, они его захотят в какой-то проект с экзотической лицензией впилить.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	142. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от arisu (ok) on 09-Май-12, 15:05
	>>> ты сейчас вот так абстрактно говоришь? >> нет, я сейчас конкретно говорю. > Конкретно какой проект ты имеешь в виду? конкретно llvm+clang. >> раз пофиг — то почему не GPL? если тебе *действительно* пофиг. > Ещё раз: мне пофиг, что будут делать с кодом те, кто его > возьмут за основу. следовательно, тебе пофиг и какая лицензия. потому что *тебе пофиг*. тогда почему не GPL? а если «GPL не позволит» и ты пы — то тебе совершенно не «пофиг», и ты лукавишь.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	180. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 10-Май-12, 16:22
	> то тебе совершенно не «пофиг», и ты лукавишь. Охренеть. Кэп поймал клыкастого тролля в эпичнейшую логическую ловушку. Снимаю шляпу, это просто шедеврально :)
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	214. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Куяврик on 16-Май-12, 15:17
	Странно потёрли ответ. Восстанавливаю. >> Конкретно какой проект ты имеешь в виду? > конкретно llvm+clang. конкретно в этом проекте разработчики уже выбрали лицензию. > следовательно, тебе пофиг и какая лицензия. именно так. > тогда почему не GPL? потому что лицензия в данном случае уже выбрана. если проект пишется "с нуля" - не вижу причин не рассматривать как вариант gpl. >  а если «GPL не позволит» и ты пы — если будет участие разработчиков, которые окажут помощь проекту, но захотят использовать наработки под другой лицензией - не вопрос. > то тебе совершенно не «пофиг», и ты лукавишь. меньше думай за других - точнее будут оценки.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	215. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от arisu (ok) on 16-Май-12, 20:35
	я вообще ни за кого не думаю, я лишь читаю то, что написано. моя ли вина, что написано было криво?
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	88. "Сравнение производительности GCC и LLVM-Clang"	–2 +/–
	Сообщение от Аноним (??) on 08-Май-12, 19:24
	> Если не устраивает лицензия ГНУ Да. Зажимать сорцы мешает. Ну как бы удачи в бесплатной работе на любителей зажимать сорцы :)
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	55. "Сравнение производительности GCC и LLVM-Clang"	+3 +/–
	Сообщение от arisu (ok) on 08-Май-12, 16:39
	> clang нужен как минимум: (далее следует список коммерческих контор и бсдошники, которым GPL как кол в анусе)
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	63. "Сравнение производительности GCC и LLVM-Clang"	+2 +/–
	Сообщение от Куяврик on 08-Май-12, 17:10
	похоже кол называется BSD и причиняет печальку тебе :)
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	65. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от arisu (ok) on 08-Май-12, 17:15
	> похоже кол называется BSD и причиняет печальку тебе :) мне всё равно, меня шланг не устраивает по другим причинам. как минимум — он не поддерживает вложеные функции. пуристы могут до посинения орать, что это не нужно, конечно — на здоровье. только gcc их поддерживает, существует под кучу архитектур и ОС. выбор очевиден.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	85. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от Аноним (??) on 08-Май-12, 19:20
	> похоже кол называется BSD Пока что я вижу как *bsd и прочие проприетарные *никсы повылетали почти отовсюду. Куда этим древностям и дорога.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	130. "Сравнение производительности GCC и LLVM-Clang"	+2 +/–
	Сообщение от Клыкастый (ok) on 09-Май-12, 07:51
	> Пока что я вижу как *bsd и прочие проприетарные это ты у себя в репке не смотрел. а ты посмотри повнимательнее, да вычисти всё не-gpl-ное. вот  это будет настоящее вегетарианство.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	181. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 10-Май-12, 16:24
	> да вычисти всё не-gpl-ное. вот  это будет настоящее вегетарианство. А если я вычищу все GPLное, у меня система не будет бутявиться и ее будет нечем собирать. Какая ж система без ядра и компилера? :) А с вашими ядрами и компилерами мои системы работать не будут, да. Потому что у вас как обычно поддержка армов и мипсов - только ан бумаге и с такими как вы каши не сваришь.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	188. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от arisu (ok) on 10-Май-12, 16:57
	(тихонечко) он не фанат-бсдшник. только никому не говори.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	207. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Куяврик on 11-Май-12, 09:27
	> А с вашими ядрами и компилерами мои системы работать не будут, да. > Потому что у вас как обычно поддержка армов и мипсов - http://www.netbsd.org/ports/ > только ан бумаге и с такими как вы каши не сваришь. чуть-чуть предмет получше представляй и всё будет окей.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	86. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от Аноним (??) on 08-Май-12, 19:21
	> похоже кол называется BSD и причиняет печальку тебе :) Ну так ты такой веселый, расскажи где твое коммерческое BSDi? Что, поставщик оного на линуксы смотался потому что их свобода зажимания сорцов оказывается не проперла клиентуру? Бывает :)
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	102. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от _yurkis_ on 08-Май-12, 21:46
	>> похоже кол называется BSD и причиняет печальку тебе :) > Ну так ты такой веселый, расскажи где твое коммерческое BSDi? Что, поставщик > оного на линуксы смотался потому что их свобода зажимания сорцов оказывается > не проперла клиентуру? Бывает :) Эмм... Помому они теперь называются ixSystems. Или я ошибаюсь?
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	118. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 09-Май-12, 01:44
	> Эмм... Помому они теперь называются ixSystems. Или я ошибаюсь? Это называлось помнится WindRiver. И оно как-то нынче барыжит ... на основе embedded Linux. Такая вот фигня. Потому что пока они там зажимали сорцы и гасили друг друга, выясняя кто у кого скопипастил и кто кому задолжал, пингвин просто развивался, писав с ноля и под лицензией исключающей такие вещи.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	167. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от _yurkis_ on 10-Май-12, 12:30
	>> Эмм... Помому они теперь называются ixSystems. Или я ошибаюсь? > Это называлось помнится WindRiver. И оно как-то нынче барыжит ... на основе > embedded Linux. Такая вот фигня. Вобще- то они живут с продажи vxWorks. Остальное вторично. Таки да, BSDi в недрах WindRiver помер. Как и многие другие коммерческие Unix. Как, скорее всего, помрет и Solaris  в недрах Oracle. Другая половина BSDi (не софтверная, как я понял) ныне называется ixSystems и пилит по старой памяти PC-BSD, FreeNAS да и вобще фряху.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	182. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 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 да и вобще фряху. К счастью это не мои проблемы уже.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	195. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от _yurkis_ on 10-Май-12, 18:16
	>Я вот вижу например что пингвин почти повыпер VxWorks в всяком soho сетевом и тому подобном оборудовании, например. Наверное потому что нынче уже нет смысла экономить на флехе 2 Мб или 4Мб или раме 4Мб или 16Мб. И то и другое жуткий low end и по цене грязи под ногами. Чип и есть чип. А фич у пингвина в разы больше, сетевых протоколы пряммее реализованы и лучше отлажены, etc. Так что не удивительно что они пингвином заинтересовались. Конкуренты подпирают + клиентура требует. Если игнорировать - у конкурентов нынче сборок пингвина под эмбеддед - хоть попой жуй! Linux не гарантирует (и никогда не будет гарантировать) время реакции на событие с точностью до такта CPU. В коммерческих встроеных системах жесткого реального времени vxWorks рулит и педалит.
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	200. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от arisu (ok) on 10-Май-12, 18:58
	> Linux не гарантирует (и никогда не будет гарантировать) время реакции на событие > с точностью до такта CPU. а что гарантирует? именно с точностью до такта?
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	202. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от _yurkis_ on 10-Май-12, 20:14
	>> Linux не гарантирует (и никогда не будет гарантировать) время реакции на событие >> с точностью до такта CPU. > а что гарантирует? именно с точностью до такта? Да
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	203. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от arisu (ok) on 10-Май-12, 21:16
	>> а что гарантирует? именно с точностью до такта? > Да что «да»? что гарантирует-то? и где об этом можно почитать? ссылочку на «с точностью до такта» можно? мне дико интересно, например.
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	212. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от _yurkis_ on 11-Май-12, 15:08
	>>> а что гарантирует? именно с точностью до такта? >> Да >что «да»? что гарантирует-то? и где об этом можно почитать? ссылочку на «с точностью до такта» можно? мне дико интересно, например. Ссылки не дам. По работе сталкивался. (В т.ч. и с приколами типа: включив сохранение FPU контекста вы получите +n тактов при переключении контекста). По большому счету vxWorks - это статически слинкованая библиотека. Многозадачность- не вытесняющая. Почему бы ей и не гарантировать?
	Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

	213. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от arisu (ok) on 11-Май-12, 15:12
	ага. то есть, «фиг его знает», на самом деле. не гарантировать, например, потому, что не все команды занимают одинаковое количество тактов. а иногда ещё прерывания могут приходить. или работать важные неразбиваемые куски. ты, однако, написал, что «гарантирует с точностью до такта». вот мне и интересно посмотреть, какая это система такое умеет — вне зависимости от чего бы то ни было. и почему эта система ещё не завоевала мир: ведь больше так не умеет никто.
	Ответить | Правка | ^ к родителю #212 | Наверх | Cообщить модератору

	126. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Клыкастый (ok) on 09-Май-12, 06:53
	> Ну так ты такой веселый, расскажи где твое коммерческое BSDi? Предполагается, что это такой тонкий троллинг?
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	183. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 10-Май-12, 16:35
	> Предполагается, что это такой тонкий троллинг? Да, это вполне прозрачный намек что оно сыграло в ящик не выдержав конкуренцию с открытым пингвином.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	208. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Куяврик on 11-Май-12, 09:50
	> Да, это вполне прозрачный намек что оно сыграло в ящик не выдержав > конкуренцию с открытым пингвином. А можно поинтересоваться источником данных такой пронзительной по мощности аналитики? Почему именно Линукс? А вот по моим данным прямыми конкурентами BSDi были BSD-системы, в том числе бесплатные. А ещё у них были лицензионные проблемы. Я понимаю, что нет сил, как хочется нарисовать себе лишнюю звезду на фюзеляже, но неплохо бы перед этим как-то подтвердить. То, что коммерческие UNIX медленно но верно слили открытым системам вопросов нет, но вы уверены, что это преимущество Linux над BSD, а не бесплатных открытых над платными закрытыми системами?
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	103. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от _yurkis_ on 08-Май-12, 21:48
	>> clang нужен как минимум: > (далее следует список коммерческих контор и бсдошники, которым GPL как кол в > анусе) Chromium? Свободные драйвера видео? Кстате, а почему Вас беспокоит анус бздюшников?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	104. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от arisu (ok) on 08-Май-12, 21:57
	> Chromium? хомки помогают гуглю писать браузер. ну, вперёд, чо. > Свободные драйвера видео? и какие это драйвера видео собираются шлангом? > Кстате, а почему Вас беспокоит анус бздюшников? потому что они со своей попаболью всенепременно прибегают сюда и начинают орать.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	107. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от iZEN (ok) on 08-Май-12, 22:10
	> и какие это драйвера видео собираются шлангом? Вот эти: % pkg_info -Ex xf86-video xf86-video-ati-6.14.3_1 xf86-video-vesa-2.3.0_2 Другие не пробовал.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	111. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от arisu (ok) on 08-Май-12, 22:47
	у меня это собрано gcc. вопрос подразумевал «какие не могут обойтись без».
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	123. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 09-Май-12, 02:36
	> у меня это собрано gcc. вопрос подразумевал «какие не могут обойтись без». А у тебя что, такая же махровая некромансия? О_О
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	140. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от arisu (ok) on 09-Май-12, 15:02
	яблочник с gcc 4.2 detected.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	184. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 10-Май-12, 16:36
	> яблочник с gcc 4.2 detected. Ты про изена? Если ты мне, у меня gcc 4.6.х в основном. Хорошо что я не яблочник, да :). С тех пор оптимизер у гцц подтянули весьма даже. А яблочники и прочие бздуны пусть и бодаются со своими жабами и религиями.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	165. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от _yurkis_ on 10-Май-12, 12:05
	>> Chromium? > хомки помогают гуглю писать браузер. ну, вперёд, чо. А другие хомки помогают гуглю делать серверную ОС (свои патчи к которой гугль, кстате, никому не показывает вобще). И что? >> Свободные драйвера видео? > и какие это драйвера видео собираются шлангом? Собираются как минимум intel. Gallium3D использует llvm для компиляции шейдеов. И он не один такой. Короче, гуглим MESA LLVM и удивляемся. >> Кстате, а почему Вас беспокоит анус бздюшников? > потому что они со своей попаболью всенепременно прибегают сюда и начинают орать. Может это линуксоиды прибежали в тему о clang со своей попоболью? Типа "gcc все равно круче ва имя луны патамушта многа платформ и GPL!".
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	71. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от Аноним (??) on 08-Май-12, 18:35
	>Я код видел. Могу подтвердить слова этого товарища. Прошу великодушно. Что же такогов в коде gcc, что мешает ему развиваться как КОМПИЛЯТОР в отличии от llvm.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	166. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от _yurkis_ on 10-Май-12, 12:08
	>>Я код видел. Могу подтвердить слова этого товарища. > Прошу великодушно. Что же такогов в коде gcc, что мешает ему развиваться > как КОМПИЛЯТОР в отличии от llvm. Ему ничего не мешает развиваться. Просто архитектура llvm изначально была создана с прицелом на модульность с четким разделением (backend / frontend) с четко формализоваными интерфейсами. Плюс в силу молодости код clang/llvm не оброс костылями.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	34. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 08-Май-12, 13:03
	ага, нашёлся тут "видитель" качества.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	73. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 08-Май-12, 18:55
	> только сам факт наличия хоть какого-то движения. Нужно уметь видеть траекторию > пути. А с этим у большинства очень туго. Надо уметь видеть траекторию пути и первую и вторую производные координат чтобы понимать куда дальше пойдет. > Продуманность архитектуры llvm/clang против бардака gcc. Таненбаум тоже втирал что микроядра - наше все. Ну и где они, ваши микроядра? Поэтому давайте говорить "гоп" после того как перепрыгнете :). Вот там то и было видно что траектория может задумана то и ничего, а вот со скоростями и ускорениями - не задалось. > Надо видеть качество, а не только количество. Ну вон Таненбаум со своим миниксом это пытался всем втереть. И где он?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	4. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 08-Май-12, 00:25
	> допилят еще clang Говорят, Apple уже сейчас вовсю пользуется допиленным clangом. Только делиться не хочет.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Сравнение производительности GCC и LLVM-Clang"	+4 +/–
	Сообщение от Алексей (??) on 08-Май-12, 01:01
	С таким же успехом эппл может использовать допиленный gcc и ни с кем не делиться - это так, мысль на подумать. Из всего llvm эпплу нужен только Objective-C (который допилен уже более чем достаточно).
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	8. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от evgeny_t (ok) on 08-Май-12, 01:20
	а свое ведро чем они будут компилить ?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	15. "Сравнение производительности GCC и LLVM-Clang"	+2 +/–
	Сообщение от Алексей (??) on 08-Май-12, 02:17
	> а свое ведро чем они будут компилить ? Да тем же мифическим допиленным GCC или CLang :)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	168. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от _yurkis_ on 10-Май-12, 14:18
	> а свое ведро чем они будут компилить ? Так хотя бы и последним gcc со своими патчами! Вы можете никогда и не узнать чем конкретно компилят OSX-IOS.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

3. "Сравнение производительности GCC и LLVM-Clang"	+6 +/–
Сообщение от Аноним (??) on 08-Май-12, 00:24
интересно посмотреть тесты на процессоре от amd
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
Сообщение от Андрей (??) on 08-Май-12, 01:04
> на ноутбуке с восьмиядерным процессором Intel Core i7 Это серьёзно? Или 4-ядерном & hyperthreading?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от Тощий Тролль on 08-Май-12, 02:18
	4 ядра + HT
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	36. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от Аноним (??) on 08-Май-12, 13:10
	ну тогда за текст выше нужно яйца отрезать.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	99. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 08-Май-12, 21:16
	Можно и не отрезать, но о квалификации писавшего это говорит достаточно красноречиво
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

7. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
Сообщение от Сергей (??) on 08-Май-12, 01:10
В большинстве тестов результаты GCC и LLVM+Clang очень близки с нулевым или небольшим перекосом в ту или иную сторону: http://openbenchmarking.org/result/1204215-SU-LLVMCLANG23 И только в паре тестов GCC ощутимо выигрывает, возможно, из-за использования MMX, SSE, AVX и т.п. Так что LLVM+Clang уже сейчас вполне себе штучка.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 08-Май-12, 01:38
	> В большинстве тестов результаты GCC и LLVM+Clang очень близки Не считая того что в 50% у шланга оптимизатор косячит и получается проигрыш в пару раз.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	12. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Sauron (??) on 08-Май-12, 01:41
	Косячит отсутствие openMP
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	84. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 08-Май-12, 19:19
	> Косячит отсутствие openMP Судя по всему - не только оно.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	24. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от an. on 08-Май-12, 10:55
	> Так что LLVM+Clang уже сейчас вполне себе штучка. Действительно, проект интересный. Но пока слишком часто еще попадается "compiler internal error". Рановато пока еще...
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
Сообщение от Сергей (??) on 08-Май-12, 01:22
Ребята из LLVM и Clang делают очень нужное дело! Молодцы! Так держать!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 08-Май-12, 01:43
	> Ребята из LLVM и Clang делают очень нужное дело! Какое?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	14. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от Алексей (??) on 08-Май-12, 02:16
	Делают отдельный фронт-енд для C++. Тот, что в GCC, к сожалению, отдельно от GCC использовать не удается.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	41. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от AdVv (ok) on 08-Май-12, 14:40
	Видимо такое-же, как в свое время делал некий Л.Торвальдс, начав писать новую ОС, хотя их и до него было написано немало.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	22. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от vaychick on 08-Май-12, 10:04
	>Ребята из LLVM и Clang делают очень нужное дело! Молодцы! Так держать! Я думаю они хотят сместить GCC с лидерского места и бороться с GNU. Что еще ожидать от Apple. Даже на вики написана цель проекта "Целью проекта является замена фронт-энда этих языков из GNU Compiler Collection (GCC). Разработка спонсируется корпорацией Apple, исходный код распространяется в рамках BSD-подобной лицензии."
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	40. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от Куяврик on 08-Май-12, 14:13
	>>Ребята из LLVM и Clang делают очень нужное дело! Молодцы! Так держать! > Я думаю они хотят сместить GCC с лидерского места и бороться с GNU. Да вы не пугайтесь расстреливать не будут. > "Целью проекта является замена фронт-энда этих языков из GNU Compiler Collection (GCC). > Разработка спонсируется корпорацией Apple, исходный код распространяется в рамках BSD-подобной лицензии." Вот интересно религиозное мышление. Написано - замена. Прочитано - бороться.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	50. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от vaychick on 08-Май-12, 16:07
	>Вот интересно религиозное мышление :) согласен - бороться добавлено от меня в сердцах. Если бы это был сторонний продукт, который предоставлял бы альтернативу и финансировался бы другой компанией, я бы порадовался, а так настораживает. >Да вы не пугайтесь расстреливать не будут. Поводов для паники нет, так как даже если GCC морально устареет, сообщество GNU придумает что-нибудь новое.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	52. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от Куяврик on 08-Май-12, 16:36
	> Поводов для паники нет, Вообще никаких. 2 свободных компилятора лучше, чем один. Какие-то там лидирующие позиции вообще не самоцель. Так что - вполне всё отлично. Успехов и тем и тем. > так как даже если GCC морально устареет, сообщество GNU придумает что-нибудь новое. дык это ж отлично! не надо только дух соревнования подменять боевым.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	56. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от vaychick on 08-Май-12, 16:40
	>не надо только дух соревнования подменять боевым. Здесь вы правы.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	60. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от arisu (ok) on 08-Май-12, 16:43
	да и соревноваться-то пока не с кем. продукты, мягко говоря, разного калибра и направленности.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	76. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 08-Май-12, 19:04
	> Да вы не пугайтесь расстреливать не будут. Ну да, только исходники зажимать. Видели уже такое в 80-90 прошлого века. Добавки не надо, спасибо.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	128. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от Клыкастый (ok) on 09-Май-12, 07:31
	> Ну да, только исходники зажимать. Видели уже такое в 80-90 прошлого века. Секта Свидетелей BSD. Лично видели как код BSD на всех компах зашифровался и местами превратился в тыкву. > Добавки не надо, спасибо. Да вам и без добавки хорошо, с 80-90 прошлого века тащит. "Завязывать надо с хиромантией, дружок..." (с)
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	187. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 10-Май-12, 16:43
	> Секта Свидетелей BSD. Лично видели как код BSD на всех компах зашифровался > и местами превратился в тыкву. BSDi вполне себе превратился, как и некоторые иные коммерческие форки/клоны/перепевки :) >> Добавки не надо, спасибо. > Да вам и без добавки хорошо, с 80-90 прошлого века тащит. Спасибо, а у нас тут 2012 год на дворе. У нас тут железки 5х5 сантиметров - типа компьютеры уже. Но ваше добро там не работает. Вот вы и тащите, х86 гробины в основном.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	209. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Куяврик on 11-Май-12, 09:55
	>> Секта Свидетелей BSD. Лично видели как код BSD на всех компах зашифровался >> и местами превратился в тыкву. > BSDi вполне себе превратился, как и некоторые иные коммерческие форки/клоны/перепевки :) Коммерческие Линуксы тоже вполне себе зигибались. И? > Спасибо, а у нас тут 2012 год на дворе. А трава с 80-х. Удобно. > У нас тут железки 5х5 сантиметров - типа компьютеры уже. Но ваше добро там не работает. Смотря какое смотря где. И кстати, ещё не вечер. Я бы попросил вас подождать и посмотреть позже. Вы же попросите меня подождать, если я спрошу про датацентр, который выкинул блейды и теперь полностью на "железках 5 на 5 типа компьютерах"?
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

10. "Сравнение производительности GCC и LLVM-Clang"	+2 +/–
Сообщение от Anonim (??) on 08-Май-12, 01:27
>> на ноутбуке с восьмиядерным процессором Intel Core i7 Фороникс шлет письма из будущего ))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Сравнение производительности GCC и LLVM-Clang"	+/–
Сообщение от pavlinux (ok) on 08-Май-12, 02:49
Пля, когда Фроникс сделает бенчмарки скорости света в вакууме, при движении фотонов справа-налево, слева-направо, снизу-вверх и сверху-вниз.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Сравнение производительности GCC и LLVM-Clang"	+2 +/–
	Сообщение от Серж (??) on 08-Май-12, 04:28
	этим займетесь вы в свободное лт работы времени
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

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

	69. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от pavlinux (ok) on 08-Май-12, 18:22
	А чё там изучать, куда дует гравитация туда быстрее и полетит, да ешё ускорение Кариолиса добавить....   :)
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	77. "Сравнение производительности GCC и LLVM-Clang"	+3 +/–
	Сообщение от Аноним (??) on 08-Май-12, 19:06
	> да ешё ускорение Кариолиса добавить....   :) Может, Кориолиса? :)
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	114. "Сравнение производительности GCC и LLVM-Clang"	+2 +/–
	Сообщение от Сергей (??) on 09-Май-12, 00:33
	От вороньева слова "каррр", поэтому пррравильно Каррриоллисса
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	124. "Сравнение производительности GCC и LLVM-Clang"	+2 +/–
	Сообщение от Аноним (??) on 09-Май-12, 02:40
	> От вороньева слова "каррр", поэтому пррравильно Каррриоллисса А, ну да, павлин каркать любит, не отнять. Иногда даже дельно каркает, но к сожалению - только иногда :(
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

21. "Сравнение производительности GCC и LLVM-Clang"	+2 +/–
Сообщение от Аноним (??) on 08-Май-12, 09:33
На соревнованиях по бегу между США и СССР выиграл американский бегун. В штатовских газетах пишут "американский бегун пришел к финишу первым". В советских - "американский бегун пришел к финишу предпоследним". Вот в сравнении LLVM и GCC все примерно так же звучит, в зависимости чей бегун таки первый пришел к финишу в данный момент.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 08-Май-12, 11:12
	> На соревнованиях по бегу между США и СССР выиграл американский бегун. > В штатовских газетах пишут "американский бегун пришел к финишу первым". > В советских - "американский бегун пришел к финишу предпоследним". ... "американский бегун пришел к финишу первым, а советский - последним" ... "советский бегун пришел к финишу вторым, а американский - предпоследним"
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

33. "Сравнение производительности GCC и LLVM-Clang"	+/–
Сообщение от Аноним (??) on 08-Май-12, 12:51
Я по ссылке увидел только в двух случаях LLVM лучше. причем на крохи (доли процента буквально).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	48. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от Сергей (??) on 08-Май-12, 15:25
	http://openbenchmarking.org/result/1204215-SU-LLVMCLANG23
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	70. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от pavlinux (ok) on 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% !!! Это надо очень постараться, чтоб так тормознуть - напихать отладочной инфы, циклов, периодически сохранять дампы и пустить все это дело через трассировщик. Но фрониксу пох...ю, они добиваются не правды, а эффекта.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	81. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 08-Май-12, 19:15
	> Я вот не верю, что один и тот же С-код может тормозить > иль наоборот разогнан на 335% !!! Вероятно оптимизатор лопухнулся и где-то в горячем месте сгенерил совсем уж гогнокод по сравнению с другим, или может асм не поюзался, или еще что-то типа того. В горячих местах лишние несколько команд спокойно могут все тормознуть в разы, если там всего несколько команд и было.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	79. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от Аноним (??) on 08-Май-12, 19:12
	> Я по ссылке увидел только в двух случаях LLVM лучше. причем на > крохи (доли процента буквально). Ну так про бегуна все верно написали. Если вы бcдун то понятное дело - эпплу надо подлизать. Если линуксоид - эппл вам не друг и не товарищ, соответственно :)
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

46. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
Сообщение от Аноним (??) on 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.dev/opennews/art.shtml?num=32275) забавно. но никто не заметил что gcc 4.7 сливает не только gcc-4.6.3 но и clang. вот такое оно будущее gcc - постоянные регрессии и тормоза.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	54. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Куяврик on 08-Май-12, 16:38
	> забавно. но никто не заметил что gcc 4.7 сливает не только gcc-4.6.3 но и clang. > вот такое оно будущее gcc - постоянные регрессии и тормоза. Не надо скоропалительных выводов. ни относительно clang, Ни относительно gcc 4.7.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	58. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от arisu (ok) on 08-Май-12, 16:42
	нет, тормоза уходят пользоваться шлангом.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	80. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 08-Май-12, 19:13
	> вот такое оно будущее gcc - постоянные регрессии и тормоза. Таненбаум, залогиньтесь :)
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	109. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 08-Май-12, 22:33
	Забавно, особенно если учесть желание GCC-шников прийти к более модульной системе как в LLVM и они предупреждали о падении скорости в будущих выпусках.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	119. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 09-Май-12, 01:48
	> вот такое оно будущее gcc - постоянные регрессии и тормоза. Ичсх, регрессию в шланг-svn (не совсем) благородный дон почему-то предпочел не заметить :). "Если факты не подтверждают теорию - от них нужно избавиться!"
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	135. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 09-Май-12, 09:01
	>> вот такое оно будущее gcc - постоянные регрессии и тормоза. > Ичсх, регрессию в шланг-svn (не совсем) благородный дон почему-то предпочел не заметить > :). "Если факты не подтверждают теорию - от них нужно избавиться!" svn это не релиз. а сравнение gcc 4.6.3 и 4.7.0 это сравнение 2х релизов :) вот если бы в релизах у clang были регрессии - тогда повод для кипиша, хотя нет - это только GNU с их цацкой GCC могут выпускать регрессии в релизах и называть фичами.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	189. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от Аноним (??) on 10-Май-12, 16:58
	> svn это не релиз. И что? Если оптимизатор перепахали - совершенно нормально что он в одних случаях может стать лучше а в других хуже. Идеальная эвристика - это вообще нечто сферическое и в вакууме. У процов еще и архитектуру перепахивают, так что то что было хорошо несколько лет назад может быть плохо вот прям ща, и наоборот. > а сравнение gcc 4.6.3 и 4.7.0 это сравнение 2х релизов :) Так надо всестороннее сравнение делать - на всех архитектурах, в куче разных задач. Разработчики ж не ставят специальной цели все сломать. Просто выиграв в одном можно проиграть в другом. Чего ради утверждается что у шланга так не будет - я не понял, в svn как раз именно такое и наблюдается вообще. > вот если бы в релизах у clang были регрессии Хотите сказать что их не было, нет и не будет? А вы точно это проверяли? На всех архитектурах и всех мыслимых типах программ? > - тогда повод для кипиша, хотя нет - это только GNU с их цацкой > GCC могут выпускать регрессии в релизах и называть фичами. Ну да, ну да, а infernal compiler error в релизе - это как называть? Фичой?
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

100. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
Сообщение от iZEN (ok) on 08-Май-12, 21:20
Поздравляю всех пользователей новых технологий — LLVM/Clang уже выглядит бодрячком на фоне старпёров и больше не просирает полимеры почём зря. (Сам использую Clang 3.0 для компиляции и сборки системы FreeBSD 9-STABLE и большей части установленных программ. Недавно портированный Chromium стал собираться системным Clang'ом.)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	120. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от Аноним (??) on 09-Май-12, 01:50
	> Поздравляю всех пользователей новых технологий Это говорит бсдшник? Ну и как там поживают твои атевые дрова ископаемой версии? А HD 7xxx у вас когда заработает? Если уж мы о новых технологиях - у амд их есть. В новом дизайне GPU еще более заточенном на вычисления.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	136. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от iZEN (ok) on 09-Май-12, 10:15
	>> Поздравляю всех пользователей новых технологий > Это говорит бсдшник? Ну и как там поживают твои атевые дрова ископаемой версии? Отлично поживают. AMD 785G показывает Full HD h.264 видео без тормозов на HP LP2475w. Летом планирую апгрейд на AMD 880G и FX-6120. У меня будет 16 ГБ ОЗУ в домашней машинке (что ускорит работу ZFS). Когда диски подешевеют, буду мигрировать RAID-Z на пул большего объёма. > А HD 7xxx у вас когда заработает? Дома в компьютерные игры не играю. > Если уж мы о новых технологиях - у амд их есть. В новом дизайне GPU еще более заточенном на вычисления. И что это мне даст?
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	193. "Сравнение производительности GCC и LLVM-Clang"	–1 +/–
	Сообщение от Аноним (??) on 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 еще более заточенном на вычисления. > И что это мне даст? Тебе? Ничего - у тебя этот драйвер будет фиг знает когда. Мне - скоростные вычисления. Которым применений - навалом. По мере внедрения фичи в открытых дровах оно пойдет в массы, т.к. у разработчиков будет как раз "по дефолту" в системах :)
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	206. "Сравнение производительности GCC и LLVM-Clang"	+/–
	Сообщение от iZEN (ok) on 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 лично для тебя?
	Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

	162. "Сравнение производительности GCC и LLVM-Clang"	+1 +/–
	Сообщение от iZEN (ok) on 09-Май-12, 23:47
	> Если уж мы о новых технологиях - у амд их есть. В новом дизайне GPU еще более заточенном на вычисления. NVIDIA тоже не отстаёт — "09.05.2012 20:52  NVIDIA передала CUDA Compiler в руки сообщества LLVM" http://www.opennet.dev/opennews/art.shtml?num=33800
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема