Успешный бутстрап (bootstrap) Clang

> Для армов и прочей встраеваемой фигни, есть профессиональные IDE с компиляторами, отладчиками и профайлерами.

Для армов все юзают gcc и твой CrossWork только морда к нему. И не он один.

>>На секундочку, а покажите-ка вы мне свой Свободный Код.

Увы - на секундочку тут не получится это сделать. Но ежели хочешь взглянуть - добро пожаловать в лабораторию, где я работаю. Тебе же на секундочку надо, не так ли?

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

Ну и да, коль уж вы там занимаетесь наукой (или пытаетесь заниматься, или даже пытаетесь делать вид, что занимаетесь), вам, думаю, будет небезынтересно прочесть о научном методе ведения дискуссии: http://ivanov-petrov.livejournal.com/1372389.html (сделайте вид, что это не я кинул ссылку, а какой-нибудь другой анонимус).

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

Тратить деньги на тех, кто ловит рейсы с отладчиком, а не «с карандашом», является верхом глупости

> Для армов все юзают gcc и твой CrossWork только морда к нему. И не он один.

Ага, только вот ARM почему-то начал активно нанимать спецов по LLVM. Интересно, на что это они тут переходить подумывают?

> Нету линакса на «спарков, powerpc, mips» - все это положили в гроб и закопали

Да-да, особенно для mips-ов!

Адсл-и почему-то на mips-ах обычно и их как бы не больше чем компов уже наделали.

А там linux/ И даже Linksys забила на свой VxWorks и вернулась на linux.

А вот спарки твои сдохли, правда.

> Интересно, на что это они тут переходить подумывают?

Никуда она не думает переходить - это всего лишь разработчик архитектуры процов

>Там как раз не GPL, а жадность фраерская проект сгубила.

ээ, дядя, а зачем глагол в прошедшем времени? Вроде же никто (окромя лор-онолитегоф и этого... какего... обиженного), пока его не закапывал? Или я чото пропустил?

> Никуда она не думает переходить - это всего лишь разработчик архитектуры процов

Ну ну, всё то ты знаешь, что и как они думают. Они кроме этого и главный поставщик всего toolchain для разработки. ARM backend в GCC написан сотрудниками ARM. И теперь они уходят на LLVM.

> Они кроме этого и главный поставщик всего toolchain для разработки

Да-да, всё то ты знаешь. Типа.

Практически главный toolchain для разработки на arm, - gcc т.к. андроид, моблин и так далее - это линуксы

ARM backend в GCC написан сотрудниками ARM

Вот и для llvm backend напишут

И теперь они уходят на LLVM.

Не уходят никуда, это не выгодно, уход с gcc _радикально_ уменьшит число потребителей arm-ов. Мало ли навороченных перспективных архитектур - avr32 та же

> Да-да, всё то ты знаешь. Типа.

Я то знаю, у меня там полно знакомых работает.

Практически главный toolchain для разработки на arm, - gcc т.к. андроид, моблин и так далее - это линуксы

Естественно, единственный официально поддерживаемый компилятор - gcc. Сейчас. И они собрались с него валить.

Вот и для llvm backend напишут

Он уже давно написан и весьма стабилен. А теперь они собрались его официально поддерживать как основной.

Не уходят никуда, это не выгодно, уход с gcc _радикально_ уменьшит число потребителей arm-ов.

Насмешил. 99.999999% потребителей ARMов наплевать на GPL с высоченной колокольни. Они пользуются тем, что удобнее. Сегодня это GCC, завтра это clang будет. Всем нормальным людям наплевать на тонкости лицензии.

> Бздуны теперь перелезут с GCC на Clang, и полностью будут бесплатно работать на мелкософт и яббл.

Кто бы говорил. Не всё же передавать ВСЕ имущественные права на GPL код какой-то странной Canonical, Red Hat или Novell. Уж лучше выпускать код со своим копирайтом под BSDL.

> Уж лучше выпускать код со своим копирайтом под BSDL.

И чем же лучше?

> И они собрались с него валить.

С какого хрена валить - бред да и только.

Естественно, единственный официально поддерживаемый компилятор - gcc

О чем и речь

99.999999% потребителей ARMов наплевать на GPL с высоченной колокольни. Они пользуются тем, что удобнее.

Ты полность прав! И когда linux будет собираться llvm - свалят на него. Или не свалят. Пока llvm тормоз.

Вооще - согласен, llvm весьма перспективен. Но перспективы тормозов не перевешивают.

Если Clang вытеснит GCC, будет очень и очень плохо - свободное ПО сильно сдаст свои позиции.

Просто код GCC давно неэффективен и не поддаётся не точ то анализу, но и рефакторингу — это как код Netscape Navigator в современном Mozilla Firefox: вроде работает, но никто не знает почему и как.

Ибо бздуны - те ещё вредители для свободного ПО.

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

> С какого хрена валить - бред да и только.

С такого, что GCC - неповоротливый монстр, в который всё труднее и труднее вносить изменения. LLVM намного проще в поддержке.

И когда linux будет собираться llvm - свалят на него. Или не свалят. Пока llvm тормоз.

А он уже очень скоро будет собираться llvm, в clang предполагается поддержка всех расширений gcc. И llvm никоим образом не тормоз. Он оптимизирует уже сейчас на 5-20% лучше в среднем, чем gcc. clang компилирует иногда в разы быстрее, чем gcc. Откуда мнение про тормознутость взялось?

>Ты напоминаешь нам о тех временах, когда в Америке после изобретения патентования Эдисоном лампочки накаливания агенты «изобретателя» рыщут в поисках нелицензионного производства и сбыта подобных источников света и через суд выбивают штрафы в пользу «изобретателя».

Ты не путай, те хоть от эдисона бабло за это получали, а Quasar так, за идею подсасывает.

С такого, что GCC - неповоротливый монстр, в который всё труднее и труднее вносить изменения. LLVM намного проще в поддержке.

Динамика LLVM тоже не очень радует, уж сколько лет пилят.

Он оптимизирует уже сейчас на 5-20% лучше в среднем, чем gcc

Можно ссылочку на бенч?

Откуда мнение про тормознутость взялось?

С первой страницы, из поста уважаемой Silvy - http://www.linux.org.ru/news/opensource/4526354#comment-4526763

GCC:
Piped 256.00 MB in 00h00m14.91s: 17.16 MB/second
Clang:
Piped 256.00 MB in 00h00m17.85s: 14.33 MB/second

Но и раньше тоже видел похожие бенчмарки - LLVM всегда тормозил.

Если Вы тестили или есть ссылки - просим!

http://clang.llvm.org/features.html#performance

> И когда linux будет собираться llvm - свалят на него. Или не свалят. Пока llvm тормоз.

На LLVM перейдут с GCC только тогда, когда Clang сможет собрать Oracle Java для архитектур arm32, amd64 и sparc64. Вот это будет поистине всем энтерпрайзам — ЭНТЕРПРАЙЗ. Всё остальное не важно и переписывается на Java в самое ближайшее 3 года.

> http://clang.llvm.org/features.html#performance

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

> http://clang.llvm.org/features.html#performance

Там ничего нет о качестве генерируемого кода.

Скорость компиляции может оказаться важной, ежели в недалеком будущем начнут компилить «на лету» в духе JIT.

> Скорость компиляции может оказаться важной, ежели в недалеком будущем начнут компилить «на лету» в духе JIT.

Верно сказал!

В репах для суси llvm не нашел, счас собираю - хочу llvm-lua потестить

http://www.phoronix.com/scan.php?page=article&item=apple_llvm_gcc&num=1

Почти в всех тестах llvm тормозит

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

Учитесь лучше в институте - узнаете.

Моя цель не победа, хотя, впрочем, не обращайте внимания, эта проблема при необходимом времени и достаточном желании действительно вполне решаема своими силами. :) Что в линуксе, что в макоси bash одинаковый.

Телефон... Телефон...

> 550тыщ это детский лепет, я участвовал в проектах в которых было ~10M строк, написанных руками.

Да я верю, дурное дело --- нихитрое. Интересно, как там с мессивостью.

> Интересно, как там с мессивостью.

3.1415здец конечно же, таких ужасов как там я нигде больше не встречал :)

В микрософте, поди, работал?

>линупс-коммунити

К логопеду, быдло!

>линакс

К логопеду, быдло!

>более 550 тысяч строк на C++

Скажите наконец разрабам что есть питон...

>Китайцы клепали ПИСИ, ПИСИ и еще раз ПИСИ и только поэтому они такие дешевые

А ПИСИ кто сделал? Уж явно не некрософт, а как бы вовсе даже IBM - это без них не было бы ни некрософта, ни штеуда, по крайней мере, в нынешнем виде.

>sparc solaris 10

В голову надо стрелять, в голову!

>линакса

К логопеду, быдло!

Нету линакса на «спарков, powerpc, mips» - все это положили в гроб и закопали

А мужики-то не знают: mvista.com, debian.org, opensuse.org...

Для реальной работы GCC намного быстрее, особенно при частых перекомпиляциях. Правда, для этого надо поставить ccache и distcc на нескольких машинах вокруг. Выигрыш при компиляции более чем одного файла - в несколько раз. То же самое можно построить и на базе MS VC, но стоит такая конфигурация приличные деньги, так что на практике я еще нигде этого не видел.

Гоняться же за качеством оптимизации смысла большого нет - практический выигрыш любой компилятор дает в пределах 10%..30%. А вот замена алгоритма на что-то более подходящее задаче дает выигрыш иногда в сотни раз. Исключений из этого очень немного, обычно когда алгоритм уже вылизан до предела.

Если же просто сравнивать опять-таки не тесты, а реальные задачи, то MSVC на Windows проигрывает GCC на таком же железе под Linux. Причем оптимизация кода здесь не настолько важна. Я как-то писал Excel read/write для больших файлов (100..200Mb). На Windows оно работало примерно вдвое медленнее, и требовало примерно вдвое больше памяти. И никакая оптимизация компилятора этот баланс не изменит. Ускорить Linux версию примерно на 20%, и Windows версию на 50% помогла перестройка программы под использование более подходящего для задачи менеджера памяти.

Очень неплохо вместо отладчика и карандаша открыть для себя valgrind --tool=helgrind. Это если нужен результат. «Карандаш», как чтение и осмысление кода, оно не заменит, но кучу дополнительной информации даст довольно быстро.

> Очень неплохо вместо отладчика и карандаша открыть для себя valgrind --tool=helgrind

valgrind ведь только для x86?

В любом случае он jtag не заменит

> В любом случае он jtag не заменит

Что такое jtag? А то я думал, что это железячное тестирование.

Очень неплохо вместо valgrind сразу чисто писать код - в общие структуры там не лазить напрямую, мутексы использовать заранее, а не когда ЖПЖП (жарны петух в жопу клюнет) :-)

>Тем более, что оно и впрямь напоминает «пятую колону».

Идеологически да, но технически очень интересно.
Не грех бы и gcc в этом направлении развиваться !

>угу, конечно, ты буст собери msvc и gcc и удивись

Есть одна проблема - msvc не сможет мне собрать ни буст, ни вообще ничего.

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

>Ты напоминаешь нам о тех временах, когда в Америке после изобретения патентования Эдисоном лампочки накаливания агенты «изобретателя» рыщут в поисках нелицензионного производства и сбыта подобных источников света и через суд выбивают штрафы в пользу «изобретателя».

И как много бабла удалось отбить у Ленина?

>Не грех бы и gcc в этом направлении развиваться !

Ну, поскольку «выбор всегда хорошо», и конкурент имеет место быть, то у gcc есть две возможности: либо включить в код, то что надо нам всем, либо слить проект.

>> Я так мыслю, лицензионная чистота (ГПЛ рулит!) превыше всякой функциональности.

Фанатики-красноглазики такие фанатики...

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

>>А окончилось как всегда диагнозом «ф топку».

Да что Вы, а ссылочку не приведете? Хотя, если имеется ввиду глупая истерия о том, что код, сгенеренный icc работает на amd медленнее, то не надо. Тут, как говорится, no comments :-D

На самом деле для проприетарного (и недешевого притом!) компилера сравнятся в тестах со свободным поделием - уже диагноз. Ну, может этот диагноз и не «ф топку», но без условно «близенко-близенко»

А, да! Обещанные сцылки забыл. Держите:

http://multimedia.cx/eggs/icc-vs-gcc-smackdown-round-3/#more-1225

http://www.usenetbinaries.com/doc/gcc_vs_icc_benchmarks_perl.html