[gentoo] clang и все-все-все.

В чем профит?

Действительно, какой реальный выйгрыш получил от clang'a?

>В чем профит?

лулзы и ЧСВ

>какой реальный выйгрыш получил от clang'a?
Очевидно же, в темноте больше не нужен фонарик, всё вокруг отлично подсвечивается красным.

>какой реальный выйгрыш получил от clang'a?

какой реальный выигрыш можно получить от gcc?
У меня все равно nouveau+llvm стоят.

> Кому еще более интересно - могу собрать ~x86/~amd64 с оптимизацией под более старые процессоры с xfce/gnome/etc..

AMD Sempron 2800+, Gnome

Лучше дай скрипт-переключалку системного компилера на шланг

Ну ты хоть бы тесты привел для сравнения GCC vs. Clang+LLVM.

Действительно, какой реальный выйгрыш получил от clang'a?

ну может уход от костыльного gcc (поддерживаемого ранее из-за безысходности) с переходом на передовые технологии поддерживаемые лидерами индустрии.

>скрипт-переключалку

Стандартная от icc (http://www.gentoo-wiki.info/HOWTO_ICC_and_Portage)

>ты хоть бы тесты привел

Скорость сборки заметно выше. На глаз скорость работы не изменилась.

А тесты недавно у похороникса были.

Охлол, лидерами индустрии это яблоками что ли?

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

>AMD Sempron 2800+, Gnome

Это который только sse умеет? Записал, сделаю.

Насколько недавно? Может к текущему моменту все изменилось в лучшую/худшую сторону?

> действительно покажут себя в деле

Ты про wine и clang слышал?

Для Ъ:

Интересный кейс: ребята из Wine провели сборку CLang вместо gcc, в результате отловили в Wine ошибок на 400кб патча :)

>Насколько недавно?

Неделю-полторы.

clang не хуже gcc в большинстве задач. на некоторых сильно быстрее, на некоторых отстает.
Кстати, там был еще и Open64, который в паре задач просто порвал gcc на куски.

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

Эх, еще бы пруфы. ;)

Охлол, лидерами индустрии это яблоками что ли?

lol это с толлман

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

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

Кто все? Какая часть? Какие платформы? Факты давай или не метанируй тут.

> выйгрыш
Facepalm.torrent

с фанатиками оперирующей анальной лексикой общаться не принято. я говорю факты и описываю реальную ситуацию. «Какие платформы?» с теми кто совсем не в теме (или прикидывается идиотом) разговаривать вообще неочем.

>посто от gcc все уходят

Причина в том, что гцц - огромный комбайн. Общепринятый, стандартный, но комбайн. Тяжелый и неповоротливый.
И многие его фичи (gcj, fortran и так далее) на десктопах не нужны.

>Эх, еще бы пруфы. ;)

Лови)
http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=commit&s=clang&sr=1

Покажи хоть один конкретный приведенный тобой факт, а то только общие слова и никакой конкретики.

Ахтунг! Грамар-наци в треде!

Он умеет SSE, SSE2, SSE3, 3DNow!, 3DNow!+, MMX, MMX+ =]

Но процессор старенький.

ааа... Это другой sempron)

>я говорю факты и описываю реальную ситуацию.

«Какие платформы?» с теми кто совсем не в теме (или прикидывается идиотом) разговаривать вообще неочем.

Анальные факты такие факты.

Ричард Столлман не одобряет. Так скоро гнулинукс перестанут гнуть

>Ричард Столлман не одобряет.

Последнее время я перестал обращать на него внимание.
Тормозить прогресс ради ПГМ не имеет смысла.

Да я ж потроллил :D

Тоже никогда не понимал, зачем гнуть линукс

>В чем профит?

Когда коту^Wгентушнику нечем занятся, он лижет^Wсобирает clang'ом

Хе, а под Athlon64 3000+ собрать не затруднит?

$ cat /proc/cpuinfo | grep flags
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow up pni cx16 lahf_lm svm extapic cr8_legacy

> Тормозить прогресс ради ПГМ не имеет смысла

Был бы прогресс ещё. Написание новых компиляторов и добавление новых фичей в линупсовую ядропомойку на прогрессе никак не отражается.

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

> ну может уход от костыльного gcc

Поведай нам, что такого костыльного в gcc тебе удалось отыскать?

Он старый, он написан на Си, он толстый и его только в 4ой версии начали делать модульным, он собирается собственными кривыми аутолулзами. А для меня как для программиста еще не всегда нравятся какие он варнинги генерит, clang в этом плане круче, и выхлоп у него читабильнее и недостатков в коде больше находит. Ну и clang написан таки на C++ и собирается няшным cmake'ом

> Он старый

Ты так говоришь, словно это что-то дурное.

он написан на Си

И что с того? Весь линакс написан на Си.

он толстый

Для оптимизирующего компилятора это нормально.

его только в 4ой версии начали делать модульным

И что с того? Она уже 4 года как выпущена.

он собирается собственными кривыми аутолулзами

Наконец-то ты назвал хоть один костыль: автотулзы. Однако автотулзы относятся к процессу сборки, и сам gcc тут не при чем.

А для меня как для программиста еще не всегда нравятся какие он варнинги генерит

А мне как программисту варнинги gcc вполне подходят. ЧЯДНТ?

Ну и clang написан таки на C++ и собирается няшным cmake'ом

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

AMD Barton MMX, 3DNow!, SSE. x86. Было бы очень интересно оптимизированный лхде , т.к. памяти всего 192 мб

> А мне как программисту варнинги gcc вполне подходят. ЧЯДНТ?

Пишите все наС

На с++ в основном пишу. stl, boost.

и как вам двухстраничный вывод, когда надо продраться черзе boost::function и boost::bind

вывод как вывод, берешь да читаешь

это не самый большой ужас:

In file included from /usr/include/boost/function/detail/maybe_include.hpp:18,
from /usr/include/boost/function/detail/function_iterate.hpp:14,
from /usr/include/boost/preprocessor/iteration/detail/iter/forward1.hpp:52,
from /usr/include/boost/function.hpp:64,
from ../../include/defer/node.h:12,
from ../../include/daserver/jsonrpcserverconnection.h:8,
from ../../include/dictionary/dictionary.h:20,
from dictionary.cpp:10:
/usr/include/boost/function/function_template.hpp: In static member function ‘static void boost::detail::function::void_function_invoker1<FunctionPtr, R, T0>::invoke(boost::detail::function::function_buffer&, T0) [with FunctionPtr = void (*)(int), R = void, T0 = void*]’:
/usr/include/boost/function/function_template.hpp:913: instantiated from ‘void boost::function1<R, T1>::assign_to(Functor) [with Functor = void (*)(int), R = void, T0 = void*]’
/usr/include/boost/function/function_template.hpp:722: instantiated from ‘boost::function1<R, T1>::function1(Functor, typename boost::enable_if_c<boost::type_traits::ice_not::value, int>::type) [with Functor = void (*)(int), R = void, T0 = void*]’
/usr/include/boost/function/function_template.hpp:1064: instantiated from ‘boost::function<R(T0)>::function(Functor, typename boost::enable_if_c<boost::type_traits::ice_not::value, int>::type) [with Functor = void (*)(int), R = void, T0 = void*]’
dictionary.cpp:181: instantiated from here
/usr/include/boost/function/function_template.hpp:112: error: invalid conversion from ‘void*’ to ‘int’

Ты в boost::function1<void, void *> пытаешься запихать «void f(int)».

Блин. это курить надо уметь

С идеей согласен. stage4 скачаю.

>оптимизированный лхде , т.к. памяти всего 192 мб

тебе точно нужна гента?)

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

>но хотелось бы чтобы максимально быстро

SliTaz? Хотя там русский не допилен, только шрифты и раскладка есть.