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

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

"Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
Сообщение от opennews (??) on 07-Ноя-11, 19:01
Ресурс Phoronix провёл (http://www.phoronix.com/scan.php?page=article&item=llvm3_gcc...) тестирование производительности кода, сгенерированного компиляторами GCC 4.6.2 (http://gcc.gnu.org), LLVM/Clang 3.0-RC1 (http://llvm.org) и  AMD Open64 4.2.5.2 (http://www.open64.net/) на платформах  Intel Sandy Bridge и AMD Shanghai. Отдельно представлены (http://www.phoronix.com/scan.php?page=article&item=amd_bulld...) результаты тестирования на платформе AMD Bulldozer. Компилятор  AMD Open64 продемонстрирвоал отличную производительность на платформах компании AMD, почти в два раза обогнав конкурентов в тесте C-Ray. Clang на 6% отстал от GCC на платформе AMD, но обогнал его на 12% на платформе Intel. В базирующемся на OpenMP тесте  Smallpt Clang значительно (в 4-6 раз) отстал от GCC, независимо от используемой платформы. В тестах 7-Zip и OpenSSL компиляторы GCC и  Clang показали примерно одинаковую производительность. В тесте John The Ripper компиляторы AMD Open... URL: http://www.phoronix.com/scan.php?page=article&item=llvm3_gcc... Новость: http://www.opennet.me/opennews/art.shtml?num=32245
Ответить | Правка | Cообщить модератору

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

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

1. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	–1 +/–
Сообщение от name (??) on 07-Ноя-11, 19:01
а сравнение сгенерированных программ по ссылке есть?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+11 +/–
	Сообщение от Анонимус_б6 on 07-Ноя-11, 19:05
	по ссылке фороникс же
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+4 +/–
Сообщение от Аноним (??) on 07-Ноя-11, 19:15
Тезис то в чём? Фороникс как обычно гонял порожняк и показал, что в зависимости от синтетического теста, можно сэмулировать крутизну любого компилятора?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	–3 +/–
	Сообщение от Имя on 07-Ноя-11, 19:23
	А скорость компиляции где? Хочу увидеть подтверждение (или опровержение) тормознутости шланга (и чё гуголь на него забил болт?).
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	–1 +/–
	Сообщение от Имя on 07-Ноя-11, 19:24
	В смысле полностью согласен с предыдущим оратором.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	7. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	–2 +/–
	Сообщение от Аноним (??) on 07-Ноя-11, 19:37
	Шланг раза в 3 быстрее gcc, вообще-то.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	9. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+3 +/–
	Сообщение от Аноним (??) on 07-Ноя-11, 19:48
	> Шланг раза в 3 быстрее gcc, вообще-то. На любых задачах или только на избранных? И где пруфлинк, кстати?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	13. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+1 +/–
	Сообщение от anonymous (??) on 07-Ноя-11, 21:08
	Cleng тормознее раза в 3. Парсер текста быстрее, а остальное все шлак. Вам парсить текст или бинарный код получать?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	14. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Аноним (??) on 07-Ноя-11, 21:12
	Без пруфлинка ты сам знаешь кто.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	16. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Аноним (??) on 07-Ноя-11, 21:37
	> Без пруфлинка ты сам знаешь кто. Автор вброса про якобы быстрый clang тоже подтверждения не привел, так что счет пока 1:1.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	20. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Аноним (??) on 07-Ноя-11, 22:58
	Первый вброс >Хочу увидеть подтверждение (или опровержение) тормознутости шланга
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	22. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Алексей (??) on 07-Ноя-11, 23:23
	На вскидку http://www.phoronix.com/scan.php?page=article&item=gcc_46_ll... http://blog.mozilla.com/respindola/2011/02/04/clang-results/ и т.п. В общем скорость компиляции clang вроде никто не оспаривал.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	24. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от анонимммм on 08-Ноя-11, 02:01
	> На вскидку > http://www.phoronix.com/scan.php?page=article&item=gcc_46_ll... > http://blog.mozilla.com/respindola/2011/02/04/clang-results/ > и т.п. В общем скорость компиляции clang вроде никто не оспаривал. можешь смело на ночь запускать сборку шланга шлангом на кор два дуо.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	25. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+1 +/–
	Сообщение от namefields on 08-Ноя-11, 09:13
	>> http://blog.mozilla.com/respindola/2011/02/04/clang-results/ В комментах пишут же, юзай gcc поновее чем 4.2 Результаты фороникса хороши для лабораторных работ - т.е. посчитать погрешность измерений.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	34. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Aleksey (??) on 08-Ноя-11, 16:40
	LLVM has another C-language family front-end called CLANG which can speed up compilation in optimization mode (-O2/-O3) upto 20%-25%.  So even as LLVM optimizations are not faster than GCC optimizations, CLANG front-end is really faster than GCC-frontend.  I think GCC community should pay more attention to this fact.  Fortunately, a few new GCC projects address to this problem and I hope this problem will be solved or alleviated. http://gcc.gnu.org/ml/gcc/2011-09/msg00043.html и соответственно тесты http://vmakarov.fedorapeople.org/spec/
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	46. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Аноним (??) on 08-Ноя-11, 18:09
	Да блин, кого эта скорость компиляции волнует? Даже простенький make допирает пересобирать только то что изменено. Поэтому при обычной разработке программы время компиляции никого не напрягает: 1-2 файла по любому на современном процессоре пересобираются быстро. Проблемы всяких отмороженных задротов, пересобирающих систему ради процесса а не результата - мало кого волнуют. И то, даже для них шланг не подарок, поскольку оптимизирует явно хуже, а местами просто вопиюще фэйлит. Поэтому растопырить пальчики в стиле "после 2 недель пересборки всех программ я получил прирост производительности на целые 2%" уже не получится. И что-то мне подсказывает что задротам будет обидно возиться с компилам если их в результате будет обгонять даже стоковая убунта с дефолтными настройками у самого последнего хомячка, который вообще не знает что такое компилятор.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	48. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 08-Ноя-11, 18:56
	> Да блин, кого эта скорость компиляции волнует? Даже простенький make допирает пересобирать > только то что изменено. Поэтому при обычной разработке программы время компиляции > никого не напрягает: 1-2 файла по любому на современном процессоре пересобираются > быстро. Посмотрите внимательно на то, как собирается какой-нибудь проект на Qt, да или вообще плюсах. Сколько времени занимает компиляция каждого объектного файла, сколько занимает конечная линковка. И да, опции "-O0 -ggdb" не забудьте, ибо они при разработке как раз используются. Бинарники на сто мегабайт, думаете, в мгновение ока записываются? А цикл "сборка-запуск" при разработке нередко раз в несколько минут, а то и ещё чаще, выполняется. > Проблемы всяких отмороженных задротов, пересобирающих систему ради процесса а не результата > - мало кого волнуют. И то, даже для них шланг не > подарок, поскольку оптимизирует явно хуже, а местами просто вопиюще фэйлит. А где-то фэйлит GCC, и что? Только у LLVM-компиляторов ещё и задел больший, и прогрессируют быстрее. > Поэтому > растопырить пальчики в стиле "после 2 недель пересборки всех программ я > получил прирост производительности на целые 2%" уже не получится. И что-то > мне подсказывает что задротам будет обидно возиться с компилам если их > в результате будет обгонять даже стоковая убунта с дефолтными настройками у > самого последнего хомячка, который вообще не знает что такое компилятор. А причём тут вообще задроты? Компилятор - инструмент разработчика. Чем собирает разработчик, тем будут собирать и все остальные.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	49. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Andrey Mitrofanov on 08-Ноя-11, 19:05
	> А причём тут вообще задроты? Зато выводы какие--vvv далекоидущие... > Компилятор - инструмент разработчика. Чем собирает разработчик, > тем будут собирать и все остальные. Вот и я говорю, у разрабов xorg-а GNU/Linux же, всем остальным понятно "чем собирать" -- какие ещё vrsafb и fbsd?.........................
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	70. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+1 +/–
	Сообщение от Аноним (??) on 11-Ноя-11, 23:50
	> Посмотрите внимательно на то, как собирается какой-нибудь проект на Qt, да или > вообще плюсах. Да нормально более-менее. Если пересобирать 1-2 файла, как это происходит при типовом процессе написания программ - проблем никаких. Или вы регулярно перелопачиваете полпроекта? А потом не задалбывает разгребать полпроекта то с вопросом "ой, где же я накосячил?" > Сколько времени занимает компиляция каждого объектного файла, Ну, несколько секунд, максимум. Учтя что при обычной пересборке проекта меняется 1-2 файла - компил и линковка укладывается в несколько секунд. > сколько занимает конечная линковка. Зависит от размера проекта, но обычно не сильно долго. > И да, опции "-O0 -ggdb" не забудьте, ибо они > при разработке как раз используются. Бинарники на сто мегабайт, думаете, в > мгновение ока записываются? Именно так: дисковый буфер любой современной машины больше 100Мб. Бинарь просто вываливается в него как в бездну, мгновенно. По той же причине линковка того что мы линковали минуту назад - испытывает аццкий cache hit и диск почти не озадачивается. А програмер использующий рухлядь где недостаточно места в памяти но при том ворочающий 100Мб бинари при этом - очевидно ССЗБ. Такое сочетание куда типичнее для задротов пересобирающих себе всю систему с поводом и без. > А цикл "сборка-запуск" при разработке нередко раз в > несколько минут, а то и ещё чаще, выполняется. Это что, разработка либрофиса на первом пентиуме с 16Мб оперативки чтоли? У меня за несколько минут соберется, пардон, ВЕСЬ довольно крупный проект на си++, с нуля. Типа battle for wesnoth или там qutim например, если уж мы о плюсах. > А где-то фэйлит GCC, и что? Только у LLVM-компиляторов ещё и задел > больший, и прогрессируют быстрее. Это шланг фэйлит - см на форониксовых тестах что и где. Гсс сфэйлил всерьез только 1 раз. Точнее, это Open64 словил Epic Win дружно обставив шланг и гцц на амд в разы. Но к сожалению оно вообще не осиливает генерить код под интел и поэтому даже такой эпичный вин ему обеспечит как максимум сильно нишевое применение (и то, там где битва за скорость числодробления до упора - GPU всяко перспективнее). > А причём тут вообще задроты? Компилятор - инструмент разработчика. Чем собирает > разработчик, тем будут собирать и все остальные. Будут. Или не будут. Зависит от. Ну вот например собирает разработчик программу вьюжлом. А под опенок его бац и нету. Соберут тем чем собирается, что есть и не создает лишних проблем или забьют.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	80. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 12-Ноя-11, 02:50
	>> Посмотрите внимательно на то, как собирается какой-нибудь проект на Qt, да или >> вообще плюсах. > Да нормально более-менее. Если пересобирать 1-2 файла, как это происходит при типовом > процессе написания программ - проблем никаких. Или вы регулярно перелопачиваете полпроекта? > А потом не задалбывает разгребать полпроекта то с вопросом "ой, где > же я накосячил?" Не обязательно перелопачивать пол-проекта, чтобы их пришлось перекомпилировать, достаточно поменять особо "популярный" хедер. Но и даже если ограничиваться модулями (типа .cxx), время тратится заметно. >> Сколько времени занимает компиляция каждого объектного файла, > Ну, несколько секунд, максимум. Учтя что при обычной пересборке проекта меняется 1-2 > файла - компил и линковка укладывается в несколько секунд. Какого проекта? Который состоит из доброй полутысячи файлов модулей и каждый бинарь в котором использует добрый десяток сторонних библиотек? На хэллоуорлде любой хоть сколько-то вменяемый компилятор будет быстрым, кто ж спорит. >> сколько занимает конечная линковка. > Зависит от размера проекта, но обычно не сильно долго. "И на том спасибо, добрый человек. А можно чуть конкретнее?", - к/ф "Ширли-мырли" >> И да, опции "-O0 -ggdb" не забудьте, ибо они >> при разработке как раз используются. Бинарники на сто мегабайт, думаете, в >> мгновение ока записываются? > Именно так: дисковый буфер любой современной машины больше 100Мб. Бинарь просто вываливается > в него как в бездну, мгновенно. По той же причине линковка > того что мы линковали минуту назад - испытывает аццкий cache hit > и диск почти не озадачивается. А програмер использующий рухлядь где недостаточно > места в памяти но при том ворочающий 100Мб бинари при этом > - очевидно ССЗБ. Такое сочетание куда типичнее для задротов пересобирающих себе > всю систему с поводом и без. Спасибо, вот теперь видно, что программированием всерьёз вы не занимаетесь. Потому что даже не понимаете, о чём говорите. Вы кроме как пропускной способности дискового интерфейса, вообще никаких причин для тормозов не видите, не? Надо рассказать, из чего эти мегабайты состоят и как формируются? >> А цикл "сборка-запуск" при разработке нередко раз в >> несколько минут, а то и ещё чаще, выполняется. > Это что, разработка либрофиса на первом пентиуме с 16Мб оперативки чтоли? У > меня за несколько минут соберется, пардон, ВЕСЬ довольно крупный проект на > си++, с нуля. Типа battle for wesnoth или там qutim например, > если уж мы о плюсах. qutim? Крупный проект? Убили наповал. :)) А насчёт игр - вы размер проекта чем меряете, мегабайтами дистрибутивного пакета? А если выкинуть ресурсы? ;) >> А где-то фэйлит GCC, и что? Только у LLVM-компиляторов ещё и задел >> больший, и прогрессируют быстрее. > Это шланг фэйлит - см на форониксовых тестах что и где. Гсс > сфэйлил всерьез только 1 раз. Точнее, это Open64 словил Epic Win > дружно обставив шланг и гцц на амд в разы. Но к > сожалению оно вообще не осиливает генерить код под интел и поэтому > даже такой эпичный вин ему обеспечит как максимум сильно нишевое применение > (и то, там где битва за скорость числодробления до упора - > GPU всяко перспективнее). Если вы надеялись, что я забыл, как выглядят те графики, то вы ошибаетесь. По новой разбирать тесты смысла не вижу, хотите спорить с чем угодно, лишь бы спорить - ваше право. >> А причём тут вообще задроты? Компилятор - инструмент разработчика. Чем собирает >> разработчик, тем будут собирать и все остальные. > Будут. Или не будут. Зависит от. Ну вот например собирает разработчик программу > вьюжлом. А под опенок его бац и нету. Соберут тем чем > собирается, что есть и не создает лишних проблем или забьют. Теоретически такое возможно, да. А к реальности не хотите вернуться? P.S.: Насчёт "не создаёт лишних проблем" - это, как вы говорите, уже окончательный epic fail с вашей стороны.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	51. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	–1 +/–
	Сообщение от iZEN (ok) on 08-Ноя-11, 19:40
	> Да блин, кого эта скорость компиляции волнует? Меня. Для систем с непрерывной интеграцией изменений важна высокая скорость компиляции исходного кода. > Даже простенький make допирает пересобирать > только то что изменено. Поэтому при обычной разработке программы время компиляции > никого не напрягает: 1-2 файла по любому на современном процессоре пересобираются > быстро. При обычной — да. На чём-то крупнее, когда несколько сторонних программных компонентов зависят от одной изменённой библиотеки — уже нет — нужно перекомпилировать всё дерево зависимостей. > Проблемы всяких отмороженных задротов, пересобирающих систему ради процесса а не результата > - мало кого волнуют. И то, даже для них шланг не > подарок, поскольку оптимизирует явно хуже, а местами просто вопиюще фэйлит. Clang'у есть куда расти. GCC достиг потолка роста и оптимизаций. > Поэтому > растопырить пальчики в стиле "после 2 недель пересборки всех программ я > получил прирост производительности на целые 2%" уже не получится. В данном случае ситуация обратная: GCC компилирует хоть и не быстро, но производит довольно шустрый код. Однако это не значит, что ради нескольких процентов общего быстродействия нужно откомпилировать всё ПО с помощью GCC и потратить на это неделю. Уж лучше потратить три дня для компиляции ПО с помощью Clang/LLVM, но получить работающий код РАНЬШЕ. > И что-то > мне подсказывает что задротам будет обидно возиться с компилам если их > в результате будет обгонять даже стоковая убунта с дефолтными настройками у > самого последнего хомячка, который вообще не знает что такое компилятор. Как на десктопе измерить быстродействие десктопных программ и сравнить, скажем, GNOME-Mplayer с кодеками, собранный Clang, и GNOME-Mplayer с кодеками, собранный GCC 4.5.x? Лично я не представляю, какие показатели быстродействия должны приниматься в расчёт. Пробовал. Собирал и тем, и этим, и GCC 4.2.2. Вроде всё одинаково реагирует на мышь и нажатие клавиш клавиатуры, воспроизведение везде одинаковое — без тормозов.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	54. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Andrey Mitrofanov on 08-Ноя-11, 21:11
	>>скорость компиляции волнует? > Меня. > Для систем с непрерывной интеграцией изменений важна высокая скорость компиляции исходного  кода. Тема тормозов и CI не раскрыта. >> Даже простенький make допирает пересобирать > зависят от одной изменённой библиотеки — уже нет — нужно перекомпилировать > всё дерево зависимостей. Уважаемому сэру кроме слова make так же ничего не говорят слова динамическая линковка и стабильный ABI? Ну да, ну да, джавва, fbsd, clang. Этапы Большого Пути. >> Проблемы всяких отмороженных задротов, пересобирающих систему ради процесса > Clang'у есть куда расти. GCC достиг потолка роста и оптимизаций. Да, не все з. ещё пересобирают систему ради $чкго-то_там_в_носу, плотенциал же ж ждя роста Шланга... ...Ждём FreeBSD 10+ -- Шланг в массы Team. Основатель-патриарьх.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	60. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от iZEN (ok) on 09-Ноя-11, 22:12
	> Уважаемому сэру кроме слова make так же ничего не говорят слова динамическая > линковка и стабильный ABI? Вы это скажите разработчикам библиотек icu, libjpeg и libpng, после изменения минорной версии которых приходится перекомпилировать 90% пакетов из дерева зависимостей десктопных приложений. > Ну да, ну да, джавва, fbsd, clang. > Этапы Большого Пути. Только причём тут FreeBSD? Она только запускает вышеописанные приложения, созданные сторонними разработчиками. Даже компиляторы, которыми производится сборка всего ПО, и то — НЕ РОДНЫЕ!
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	61. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 09-Ноя-11, 22:14
	>> Уважаемому сэру кроме слова make так же ничего не говорят слова динамическая >> линковка и стабильный ABI? > Вы это скажите разработчикам библиотек icu, libjpeg и libpng, после изменения минорной > версии которых приходится перекомпилировать 90% пакетов из дерева зависимостей десктопных > приложений. Речь совсем не об этом, перечитайте тред.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	62. "Сравнение производительности компиляторов GCC 4.6,..."	+/–
	Сообщение от arisu (ok) on 09-Ноя-11, 23:32
	> Clang'у есть куда расти. GCC достиг потолка роста и оптимизаций. а вот с этого места давай поподробней. с ссылочками, разбором технологий ллвм и технологий гцц. не, я понимаю, что ты сейчас опять сольёшься и сделаешь вид, что этого камента не видел. но мало ли…
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	66. "Сравнение производительности компиляторов GCC 4.6,..."	+/–
	Сообщение от iZEN (ok) on 10-Ноя-11, 01:51
	>> Clang'у есть куда расти. GCC достиг потолка роста и оптимизаций. > а вот с этого места давай поподробней. с ссылочками, разбором технологий ллвм и технологий гцц. Технология у GCC закрытая: промежуточный код недоступен для изучения и оптимизаций сторонним разработчикам. На этом точки роста GCC убиты в зародыше. В LLVM можно оптимизировать в том числе промежуточный код сторонними оптимизаторами. В этом точки роста LLVM/Clang.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	67. "Сравнение производительности компиляторов GCC 4.6,..."	+1 +/–
	Сообщение от arisu (ok) on 10-Ноя-11, 01:57
	> Технология у GCC закрытая: промежуточный код недоступен для изучения и оптимизаций сторонним > разработчикам. лолчто? а, впрочем, понимаю: он же не на яве, а ты больше ничего и не знаешь. в частности, и того, что всё спокойно экспортируется, существует система плугинов и ещё много всего. и то правда: зачем тебе всякую фигню знать? главное — сказать какую-нибудь феерическую чушь и радоваться. > В LLVM можно оптимизировать в том числе промежуточный код сторонними оптимизаторами. В > этом точки роста LLVM/Clang. (ржот) угу. а в гцц, видимо, нельзя. слушай, на свете вообще есть хоть одна вещь, о которой ты говоришь *после* её изучения, а не *вместо*?
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	68. "Сравнение производительности компиляторов GCC 4.6,..."	+/–
	Сообщение от iZEN (ok) on 10-Ноя-11, 02:17
	Читать до просветления: http://kemiisto.blogspot.com/2010/08/gcc-45-link-time-optimi... — промежуточное представление кода на стадии компиляции появилось только в GCC 4.5.0, а отвязалось от Linux только в GCC 4.5.1:     GCC's new link-time optimizer (-flto) now also works on a few non-ELF targets:     Cygwin (*-cygwin*)     MinGW (*-mingw*)     Darwin on x86-64 (x86_64-apple-darwin*) О какой кроссплатформенности LTO в GCC и применимости его в продакшене может идти речь, в то время, когда в LLVM source- and target-independent optimizer "из коробки" ПРОСТО РАБОТАЕТ. Пока просто, дальше — поглядим. Оптимизации на основе Register Transfer Language (RTL) GCC и Intermediate Representation (IR) LLVM не будем сравнивать, а?
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	71. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+1 +/–
	Сообщение от Аноним (??) on 12-Ноя-11, 00:24
	>> Да блин, кого эта скорость компиляции волнует? > Меня. А ты вообще на яве программируешь вроде? :) > Для систем с непрерывной интеграцией изменений важна высокая скорость > компиляции исходного кода. Я вроде просил задротов помешаных на пересборке всей системы с поводом и без не беспокоиться. С ними и так все понятно - им по определению некуда время девать. И mission critical задач у них нет. >> никого не напрягает: 1-2 файла по любому на современном процессоре пересобираются >> быстро. > При обычной — да. На чём-то крупнее, когда несколько сторонних программных компонентов > зависят от одной изменённой библиотеки — уже нет — нужно перекомпилировать > всё дерево зависимостей. Простите, если я разрабатываю библиотеку, пусть уж остальные сами перекомпиливают свои программы где им там надо и сколько надо с новой версией. Автор библы лопнет все программы пересобирать. Попробуй пересобрать для начала все программы использующие zlib? А зачем бы это тому кто поменял zlib? И динамическая линковка конечно же не комильфо? > Clang'у есть куда расти. GCC достиг потолка роста и оптимизаций. А подвести научное обоснование всему этому вы сможете? Или это как обычно, попытка выдачи желаемого за действительное? Вон open64 показал что в одном конкретном тесте можно и шланга и гнутый си раза в три натянуть. Но это видимо злостная оптимизация под конкретный процессор. Такой код не будет работать на другом проце, что резко снижает полезность фичи. >> растопырить пальчики в стиле "после 2 недель пересборки всех программ я >> получил прирост производительности на целые 2%" уже не получится. > В данном случае ситуация обратная: GCC компилирует хоть и не быстро, но > производит довольно шустрый код. Однако это не значит, что ради нескольких > процентов общего быстродействия нужно откомпилировать всё ПО с помощью GCC и > потратить на это неделю. Так ни один нормальный человек и не компилит все ПО. Не тратя на это ни день ни неделю. Это удел только сирых и убогих, у которых почему-то еще нет пакетных менеджеров да красноглазых задротов готовых ради 2% сношаться неделю. Такие еще судорожно перекомпиливают ядро, осознав что в нем нету модуля для только что воткнутой флехи принесенной другими людьми, потому что в погоне за экономией аж 10кб кода он прибил соответствующий модуль. > Уж лучше потратить три дня для компиляции ПО с помощью Clang/LLVM, > но получить работающий код РАНЬШЕ. А еще лучше не страдать этим онанизмом и поставить себе за 20 минут систему с бинарными пакетами. Сэкономив себе от трех дней до недели геморроя неизвестно зачем. А зачем мне пересобирать весь софт самолично? Я что, собираюсь выпускать свой дистр и майнтенансить в нем все пакеты? Или чем таким либрофис собранный мной лично будет лучше либрофиса из пакета, при условии что я не разработчик либры и поэтому ничего в нем не менял? >> в результате будет обгонять даже стоковая убунта с дефолтными настройками у >> самого последнего хомячка, который вообще не знает что такое компилятор. > Как на десктопе измерить быстродействие десктопных программ и сравнить, > скажем, GNOME-Mplayer с кодеками, собранный Clang, и GNOME-Mplayer > с кодеками, собранный GCC 4.5.x? Бенчмаркать сам gnome-mplayer смысла довольно мало. Это лишь оболочка для сосиски. А мплеер (скорость работы которого и роялит) забенчить можно примерно так: пустить декод с максимальной скоростью и сравнить достигаемые FPS-ы (man mplayer, в районе -benchmark и связанных с ним опций). С -vo null есть все шансы забенчить забористость кодека :).Можно и на MEncoder погонять транскодирование формата в формат, движок с кодеками тоже мплееровский. > Лично я не представляю, какие показатели быстродействия должны приниматься в расчёт. В конечном итоге роялит максимальный FPS который можно выжать. Если он заведомо больше нужного - нагрузка на CPU (вой кулера на проце вкалывающем на пределе возможностей тоже мало кого радует). В чем прикол мерять максимальный FPS? На тяжелых мувиках мы или укладываемся в реалтайм с их FPSом, или нет. Лучше уложиться, потому что слайдшоу выглядит как-то, гм, не очень. А дропнуть кадр если ну никак не успеваем без сильного ущерба для качества картинки можно не всегда и не во всех кодеках. Поэтому если в реалтайм не уложиться, тяжелый мувик на интенсивной сцене может немало разочаровать. А так - чем быстрее плеер, тем более ядреный мувик он осилит софтварно. Тем более что хардварное акселерирование мало того что очень капризно к формату потока, так поди еще и отсутствует в опенке как класс. > Пробовал. Собирал и тем, и этим, и GCC 4.2.2. Вроде всё > одинаково реагирует на мышь и нажатие клавиш клавиатуры, воспроизведение везде > одинаковое — без тормозов. Не умеете вы плееры бенчмаркать. См. выше как можно побенчить именно кодеки. На самом деле - достаточно любопытный бенч, на который вполне любопытно было бы натравить все три сабжевых компилера и посмотреть кто кого и где. Правда есть подозрение что поскольку ломовую работу часто выполняют асмовые вставки, отличия могут быть не столь уж драматичны, поскольку если человек явно указал что разложить асм вот так - тут оптимизатор компилера как-то не имеет правов рыпаться. Но тем не менее, на участках между горячими кусками компилер наверное может сколько-то процентов отыграть. Хотя основной отыгрыш разумеется в горячих кусках (замена сишного кода на асм дает прирост буквально в разы). Еще кстати дарю идею: можно качнуть vp8 и x264 и забенчить и их. У них есть свои утилитки-энкодеры, относительно простые, консольные. Тоже достаточно любопытно в принципе посмотреть на соотношения скоростей. Фороникс какие-то странные и не сильно жизненные задачи выбирает. Ну вот например нахрена б вам в повседневной жизни c-ray? Ну и мне он примерно туда же :)
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	81. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от iZEN (ok) on 13-Ноя-11, 09:06
	>>> Да блин, кого эта скорость компиляции волнует? >> Меня. > А ты вообще на яве программируешь вроде? :) Уже нет. А что? >> Для систем с непрерывной интеграцией изменений важна высокая скорость >> компиляции исходного кода. > Я вроде просил задротов помешаных на пересборке всей системы с поводом и > без не беспокоиться. Дык, сишноориентированные системы до сих пор не развились до уровня бинарной модульности OSGi или хотя бы EJB. Всё у них какие-то "деревянные" зависимости от libjpeg, libpng и icu, что при изменении минорной версии этих библиотек весь десктоп нужно переколбашивать (пересобирать/ждать корректирующих обновлений всех зависимостей), а иначе работать ничего не будет. :)) > С ними и так все понятно - им > по определению некуда время девать. И mission critical задач у них > нет. Так в том-то и дело, что некуда с подводной лодки деваться — у сишноориентированных систем нету тех технологий, что есть в Java, и ABI у ключевых библиотек нестабилен (что удивительно). > Простите, если я разрабатываю библиотеку, пусть уж остальные сами перекомпиливают свои > программы где им там надо и сколько надо с новой версией. > Автор библы лопнет все программы пересобирать. Попробуй пересобрать для начала все > программы использующие zlib? А зачем бы это тому кто поменял zlib? > И динамическая линковка конечно же не комильфо? В динамической линковке нестабильный ABI не отменяется — это к примеру по icu, jpeg, png. :)) >> Clang'у есть куда расти. GCC достиг потолка роста и оптимизаций. > А подвести научное обоснование всему этому вы сможете? Или это как обычно, > попытка выдачи желаемого за действительное? Clang/LLVM УЖЕ интересен. GCC ЕЩЁ интересен. Разница, такая разница. ;) >> Уж лучше потратить три дня для компиляции ПО с помощью Clang/LLVM, >> но получить работающий код РАНЬШЕ. > А еще лучше не страдать этим онанизмом и поставить себе за 20 > минут систему с бинарными пакетами. Ага. И уповать на то, что мантейнеры всё собрали в лучшем виде, именно так, как тебе нужно. :) > Сэкономив себе от трех дней до недели геморроя неизвестно зачем. > А зачем мне пересобирать весь софт самолично? "Зачем готовить дома на кухне, если можно пойти в ресторан МакДональдса и быстро поесть?" Чтобы контролировать свои потребности в конкретном софте и его функциональности. >> Лично я не представляю, какие показатели быстродействия должны приниматься в расчёт. > В конечном итоге роялит максимальный FPS который можно выжать. Ты латентный задрот? Мне хватает того, что MPlayer собирается БЫСТРО и работает нормально. Самоцель не то, чтобы всё работало максимально быстро, а то, чтобы всё собиралось БЫСТРО, без ненужных зависимостей (я выкинул из MPlayer ненужный мне FFMpeg) и работало ОПТИМАЛЬНО. > Если он заведомо > больше нужного - нагрузка на CPU (вой кулера на проце вкалывающем > на пределе возможностей тоже мало кого радует). В чем прикол мерять > максимальный FPS? На тяжелых мувиках мы или укладываемся в реалтайм с > их FPSом, или нет. Лучше уложиться, потому что слайдшоу выглядит как-то, > гм, не очень. А дропнуть кадр если ну никак не успеваем > без сильного ущерба для качества картинки можно не всегда и не > во всех кодеках. Поэтому если в реалтайм не уложиться, тяжелый мувик > на интенсивной сцене может немало разочаровать. Пусть разработчики кодеков меряют FPS'ы и тюнят свой код. Моё дело собрать и пользоваться ИХ кодом, либо НЕ собирать и НЕ пользовать им. > Еще кстати дарю идею: можно качнуть vp8 и x264 и забенчить и > их. У них есть свои утилитки-энкодеры, относительно простые, консольные. Тоже достаточно > любопытно в принципе посмотреть на соотношения скоростей. Фороникс какие-то странные и > не сильно жизненные задачи выбирает. % pkg_info libvpx-0.9.7 Information for libvpx-0.9.7: Comment: VP8 Codec SDK Required by: gnome-mplayer-1.0.0_2 mplayer-1.0.r20110329_3 Description: libvpx is the VP8 Codec SDK. WWW:    http://www.webmproject.org/ % pkg_info x264-0.116.2076 Information for x264-0.116.2076: Comment: Library and tool for encoding H.264/AVC video streams Required by: libquicktime-1.2.3_1 Description: x264 is a free library for encoding H.264/AVC (aka MPEG-4 Part 10) video streams. Encoder features * CAVLC/CABAC * Multi-references * Intra: all modes (4x4 and 16x16 with all predictions) * Inter P: all partitions (from 16x16 down to 4x4) * Inter B: partitions from 16x16 down to 8x8 (including SKIP/DIRECT) * Ratecontrol: constant quantizer, constant bitrate, or multipass ABR * Scene cut detection WWW:    http://www.videolan.org/x264.html
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	8. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+1 +/–
	Сообщение от Аноним (??) on 07-Ноя-11, 19:47
	> и чё гуголь на него забил болт? Разработкой шланга дирижирует яббл, а у них с гуглом отношения, мягко говоря, натянутые //К.О.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	21. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Аноним (??) on 07-Ноя-11, 23:01
	> Разработкой шланга дирижирует яббл, а у них с гуглом отношения, мягко говоря, > натянутые //К.О. А мы делаем ставки - кто же из бобра с ослом все-таки натянет ближнего своего.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	33. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Аноним (??) on 08-Ноя-11, 15:44
	> А мы делаем ставки - кто же из бобра с ослом все-таки натянет ближнего своего. В любом случае, это не мешает им и сейчас благополучно натягивать юзеров =\
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	36. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Аноним (??) on 08-Ноя-11, 17:34
	> Тезис то в чём? Фороникс как обычно гонял порожняк Сделайте лучше, ждем!
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	44. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Аноним (??) on 08-Ноя-11, 18:05
	> Сделайте лучше, ждем! Никто не может сравниться с форониксом в таком сложном и нужном деле, как сравнение теплого с мягким!
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

6. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+8 +/–
Сообщение от Аноним (??) on 07-Ноя-11, 19:34
Короткий пересказ статьи: "Циклюю пол. Быстро. Правда хреново."
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+3 +/–
	Сообщение от Аноним (??) on 07-Ноя-11, 19:58
	> "Циклюю пол. Быстро. Правда хреново." До этих слов можно сократить любой форониксовский бенчмарк.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

11. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
Сообщение от Андрей (??) on 07-Ноя-11, 20:18
А как же PathScale EKOPath 4, который недавно стал свободным, хотя его на главной страничке по-прежнему предлагают за 1795 зелёных?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от fontpath on 07-Ноя-11, 20:22
	> А как же PathScale EKOPath 4, который недавно стал свободным, хотя его > на главной страничке по-прежнему предлагают за 1795 зелёных? Это фактически Open64 с плюшками, по крайней мере у них один предок - SGI MIPSpro, который был лучшим компилятором когда-либо мной используемых.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	15. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от anonymous (??) on 07-Ноя-11, 21:19
	> А как же PathScale EKOPath 4, который недавно стал свободным, хотя его > на главной страничке по-прежнему предлагают за 1795 зелёных? Судя по треду в gcc-devel их заподозрили в том что хотят нахаляву чтото свое протолкнуть в основную ветку gcc-fortran и соответственно как то хитро утащить оттуда себе кусок. Насколько я понял, ради этого они и открыли код, но были "разоблачены" бдительными бойцами gcc. Чем кончилось не знаю, фортран не интересен, читал разборки просто случайно. Может давно помирились, стали белыми и пушистыми и вместе коммитят код в gcc. Но код они открыли это факт. На страничке старая инфа так как нанимали фрилансера рисовать сайт, он давно сделал и свалил. надо нового искать. Но вообще я так понял фуфел этот pathscale, любой якобы 'в 5 раз более быстрый код' на самом деле получается gcc c твикингом ключей. Нет так никакой магии.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	28. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Andrew Kolchoogin on 08-Ноя-11, 10:22
	> Но вообще я так понял фуфел этот pathscale, любой якобы 'в 5 раз более быстрый код' > на самом деле получается gcc c твикингом ключей. Нет. Если взять то, что _действительно_ медленно работает -- ну, к примеру, Ab Initio-программы для расчётов в квантовой теории -- то, во-первых, получится, что Фортран интересен, ибо они на нём, собственно, и написаны, а во-вторых, gcc -- тормоз, и "твикинг ключей" ему не помогает. GFortran'у, в смысле.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	39. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Аноним (??) on 08-Ноя-11, 17:57
	> gcc -- тормоз, и "твикинг ключей" ему не помогает. GFortran'у, в смысле. Тогда этот pathscale тоже должен быть бесполезен.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	47. "Сравнение производительности компиляторов GCC 4.6, LLVM/Clan..."	+/–
	Сообщение от Аноним (??) on 08-Ноя-11, 18:12
	> gcc -- тормоз, и "твикинг ключей" ему не помогает. GFortran'у, в смысле. А что, шланг умеет компилить фортран?
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

17. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
Сообщение от Аноним (??) on 07-Ноя-11, 22:02
Осмотрел оригинальную статью и не нашел ничего про уровни оптимизации. ИМХО, ерунда это все.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от Аноним (??) on 07-Ноя-11, 22:37
	Не надо к этом так серьезно относиться, это же фороникс!
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	23. "Сравнение производительности результирующего кода GCC 4.6, L..."	–1 +/–
	Сообщение от ononom on 08-Ноя-11, 01:23
	от ваших ярлыков про фороникс тошнит сильней, чем от того, на чём эти ярлыки висят. фороникс совршает действия, получает опыт и какие-никакие результаты. в конечном счёте они будут делать это лучше. но школоте и быдлу (большая часть комментаторов тут) ведь это не важно, верно? главное пёдрнуть посильней
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	38. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от Аноним (??) on 08-Ноя-11, 17:56
	Мистер Фороникс, залогиньтесь! > главное пёдрнуть посильней Как емко и точно описана вся ваша бенчмарковская деятельность!
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	59. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от ononom on 09-Ноя-11, 02:27
	нет, ты!
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	63. "Сравнение производительности результирующего кода GCC..."	+/–
	Сообщение от arisu (ok) on 09-Ноя-11, 23:36
	> фороникс совршает действия, получает опыт и какие-никакие результаты. резальтатом бессмысленных действий обычно является ненужный опыт и бессмысленные результаты. собственно, именно так всё и обстоит у похороникса: уж сколько лет действия совершают, а толку никакого.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	72. "Сравнение производительности результирующего кода GCC..."	+/–
	Сообщение от Аноним (??) on 12-Ноя-11, 00:28
	> действия совершают, а толку никакого. Не, почему, про видеоподсистему дельно пишут временами. Иногда файловые системы бенчат сносно. Остальные тесты отлчиаются странным набором параметров или тестируют не то что должны бы. Но все-таки мир не черно белый и даже фороникс временами выдает на гора вполне дельные результаты.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	75. "Сравнение производительности результирующего кода GCC..."	+/–
	Сообщение от arisu (ok) on 12-Ноя-11, 00:46
	> даже фороникс временами выдает на гора вполне дельные результаты. только лень разбираться каждый раз, накосячили они или нет. проще считать, что накосячили: в большинстве случаев это будет верно.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

19. "Сравнение производительности результирующего кода GCC 4.6, L..."	–2 +/–
Сообщение от denis111 (ok) on 07-Ноя-11, 22:42
Фороникс, не фороникс, итак ясно, что ГЦЦ, ну и в последнее время ЦЛанг покажут лучший результат в целом. А тесты от амд, это как тесты от ител, это нельзя сравнивать.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	26. "Сравнение производительности результирующего кода GCC 4.6, L..."	–4 +/–
	Сообщение от Аноним (??) on 08-Ноя-11, 10:00
	лучше сказать gcc это отработаный шлак, будущее за новыми компиляторами с более вменяемой архитектурой. gcc пока живет на своей исключительности - но конец его уже близок.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	29. "Сравнение производительности результирующего кода GCC 4.6, L..."	+3 +/–
	Сообщение от emg81 (ok) on 08-Ноя-11, 12:51
	аргументы о невменяемости архитектуры GCC можно в студию? P.S. давно слежу за LLVM/Clang - оно пока ещё даже далеко не всё собирает + производительность бинарного кода в редких случаях лучше, чем у GCC. ну и скорость *сборки*, да, выше. в остальном GCC выигрывает. как по мне, так разговоры о том, что LLVM/Clang хоть сколько-нибудь сейчас является заменой GCC, а GCC - старый неповоротливый монстр с "невменяемой архитектурой" чем-то похожи на вопли граждан о Linux и HURD. Мол, Linux загадили корпорации, там страшный 12309, тупая архитектура, а вот HURD - это мегасупернанотехнология, всё ультраправильно и идеально конечно, ДА. только пока не особо хорошо работает и по функционалу и поддерживаемым архитектурам/железу до Linux как до Пекина улитке. но вот *скоро* выйдет и Linux спишут на свалку истории. угу, ждём-с замены Linux на HURD и GCC на LLVM/Clang :)
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	31. "Сравнение производительности результирующего кода GCC 4.6, L..."	–2 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 08-Ноя-11, 14:16
	> аргументы о невменяемости архитектуры GCC можно в студию? > P.S. давно слежу за LLVM/Clang - оно пока ещё даже далеко не > всё собирает + производительность бинарного кода в редких случаях лучше, чем > у GCC. ну и скорость *сборки*, да, выше. > в остальном GCC выигрывает. Это далеко не всё, вообще-то. (см ниже) > как по мне, так разговоры о том, что LLVM/Clang хоть сколько-нибудь сейчас > является заменой GCC, а GCC - старый неповоротливый монстр с "невменяемой > архитектурой" чем-то похожи на вопли граждан о Linux и HURD. Мол, > Linux загадили корпорации, там страшный 12309, тупая архитектура, а вот HURD > - это мегасупернанотехнология, всё ультраправильно и идеально > конечно, ДА. > только пока не особо хорошо работает и по функционалу и поддерживаемым архитектурам/железу > до Linux как до Пекина улитке. но вот *скоро* выйдет и > Linux спишут на свалку истории. > угу, ждём-с замены Linux на HURD и GCC на LLVM/Clang :) Hurd - академический проект, не путайте. Если какой-то идиот такое говорит, что Hurd заменит Linux, флаг ему в руки. LLVM/CLang - вещь практическая, уже сейчас много чего умеющая, с потенциалом _большим_, чем у GCC (вон, недавно LLVM прикрутили к запуску гномошелла на машинах без 3D - почему не GCC? Вопрос риторический). А если бы вы когда-нибудь разбирали простыни ошибок GCC и CLang, думаю, вы бы очень хорошо подумали о том, кто из них адекватнее. Потеря времени на разбор - порой неверных! - сообщений об ошибках от GCC обходится реальными затратами, ибо время - деньги. Затраты на разработку => конечный продукт получается либо дороже, либо хуже. И скорость сборки, между прочим, сюда же. Лично я жалею, что не начал CLang'ом штатно пользоваться раньше, сэкономил бы кучу нервов на отладке ошибок при использовании STL и boost. Ну да, на небольших проектах преимущество в скорости сборки не будет заметно. Но небольшие проекты и CLang'ом собираются исправно. Что же до монстров вроде целой *BSD или *Office - наблюдается быстрый и неуклонный прогресс. Собственно, если правильно помню, LibreOffice и некоторые платформы FreeBSD уже CLang'ом собираются без проблем. В общем, попробуйте сначала и сравните сами. Потом уже будет о чём разговариваеть.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	35. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от Аноним (??) on 08-Ноя-11, 16:48
	> аргументы о невменяемости архитектуры GCC можно в студию? Можно. Посмотри код GCC. Посмотри код Clang. Все вопросы пропадут сами собой. > Мол, Linux загадили корпорации, там страшный 12309, тупая архитектура, а вот HURD - это мегасупернанотехнология, всё ультраправильно и идеально 200707-walfield-critique-of-the-GNU-Hurd.pdf
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	41. "Сравнение производительности результирующего кода GCC 4.6, L..."	+2 +/–
	Сообщение от Аноним (??) on 08-Ноя-11, 18:02
	>> аргументы о невменяемости архитектуры GCC можно в студию? > Можно. Посмотри код GCC. Посмотри код Clang. Все вопросы пропадут сами собой. Человек, кажется, просил аргументы за clang и против gcc, а то, что вы предлагаете - строго обратное.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	53. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от iZEN (ok) on 08-Ноя-11, 20:10
	> аргументы о невменяемости архитектуры GCC можно в студию? > P.S. давно слежу за LLVM/Clang - оно пока ещё даже далеко не всё собирает. Это GCC 4.6.x далеко не всё собирает. У меня системный Clang/LLVM не собирает только эти программы: devel/icu multimedia/mp4v2 audio/libaacplus multimedia/libquicktime graphics/netpbm net-p2p/libtorrent-rasterbar archivers/thunar-archive-plugin misc/xfce4-weather-plugin Остальные ~400 десктопных приложений и библиотек GNOME 2.32/Gtk2, включая OpenJDK6 и 7, нормально компилируются. > в остальном GCC выигрывает. В чём ещё? Лично я теперь могу выбирать, каким компилятором откомпилировать конкретное приложение, и расставить соответствующие условия компиляции в make.conf. > угу, ждём-с замены Linux на HURD и GCC на LLVM/Clang :) Причём тут HURD?! Clang/LLVM собирает практически годную для промышленного использования (с некоторыми оговорками — и для для десктопа) ОС FreeBSD 9-RC1.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	73. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от Аноним (??) on 12-Ноя-11, 00:31
	> собирает практически годную для промышленного использования Это такой вариант фразы про "немножечко беременна"?! :)))
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	40. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от Аноним (??) on 08-Ноя-11, 17:59
	> лучше сказать clang это отработаный шлак, будущее за проверенными компиляторами с более вменяемой архитектурой. > clang пока живет на деньги apple - но конец его уже близок. Починил.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

27. "Сравнение производительности результирующего кода GCC 4.6, L..."	–1 +/–
Сообщение от PereresusNeVlezaetBuggy (ok) on 08-Ноя-11, 10:04
А теперь ждём извинений от крикунов, ещё в этом году здесь же, на Опеннете, громко заявлявших, что CLang никогда не догонит GCC по скорости конечного кода из-за лицензии/сообщества/опыта/etc... (в том числе по результатам форониксовских тестов, ага)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	30. "Сравнение производительности результирующего кода GCC 4.6, L..."	+1 +/–
	Сообщение от emg81 (ok) on 08-Ноя-11, 13:02
	> А теперь ждём извинений от крикунов, ещё в этом году здесь же, > на Опеннете, громко заявлявших, что CLang никогда не догонит GCC по > скорости конечного кода из-за лицензии/сообщества/опыта/etc... (в том числе по результатам > форониксовских тестов, ага) и где же он догнал-то? 1. это фороникс. т.е. информация Just For Fun и т.д. 2. что GCC, что LLVM/Clang - RC. 3. как мне кажется, имеет смысл сравнивать не только с GCC-4.6.2, но и с 4.5.3 и 4.4.6, т.к. в *конкретной* версии 4.6.2 могли быть существенные регрессии, потому Clang в бенчмарках рядом. 4. что, Clang'ом уже можно собирать под столько же архитектур, сколько с GCC и такое же количество программ? вроде целые новости были, что LibreOffice будут делать патчи для Clang, чтобы Clang'ом можно было собрать LibreOffice. т.е. разработчики ПО, которое нормально собирается другим компилятором (GCC) правят свой код, чтобы Clang'ом можно было его собрать. нормальный подход, да. P.S. я не GCC-фанатик, просто давайте смотреть фактам в глаза и здраво их оценивать
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	32. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 08-Ноя-11, 14:23
	>> А теперь ждём извинений от крикунов, ещё в этом году здесь же, >> на Опеннете, громко заявлявших, что CLang никогда не догонит GCC по >> скорости конечного кода из-за лицензии/сообщества/опыта/etc... (в том числе по результатам >> форониксовских тестов, ага) > и где же он догнал-то? > 1. это фороникс. т.е. информация Just For Fun и т.д. Наезды на тормознутость CLang'а тоже делались на основе Phoronix'овских тестов. > 2. что GCC, что LLVM/Clang - RC. Простите?.. > 3. как мне кажется, имеет смысл сравнивать не только с GCC-4.6.2, но > и с 4.5.3 и 4.4.6, т.к. в *конкретной* версии 4.6.2 могли > быть существенные регрессии, потому Clang в бенчмарках рядом. Угу. Только у CLang'а их почему-то не было. > 4. что, Clang'ом уже можно собирать под столько же архитектур, сколько с > GCC и такое же количество программ? вроде целые новости были, что > LibreOffice будут делать патчи для Clang, чтобы Clang'ом можно было собрать > LibreOffice. Ещё нет - но это уже больше экстенсивное развитие, при текущей скорости прогрессирования LLVM-семейства вопрос нескольких лет. > т.е. разработчики ПО, которое нормально собирается другим компилятором (GCC) правят свой > код, чтобы Clang'ом можно было его собрать. нормальный подход, да. Если код был изначально написан с GCC-измами - что весьма и весьма не редкость - то от патчей никуда не денешься. CLang, конечно, поддерживает часть интересных атрибутов и проч., но не более. А ещё порой бывают неявные зависимости/привязки, когда ошибочный изначально код вследствие особенностей одного компилятора отрабатывает правильно, но начинает валиться на другом. > P.S. я не GCC-фанатик, просто давайте смотреть фактам в глаза и здраво > их оценивать Факты таковы, что CLang _интереснее_ GCC.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	42. "Сравнение производительности результирующего кода GCC 4.6, L..."	+1 +/–
	Сообщение от Аноним (??) on 08-Ноя-11, 18:02
	> Наезды на тормознутость CLang'а тоже делались на основе Phoronix'овских тестов. Ну так и эти тесты ее показали. Единственное место где шланг себя проявил - DES шифрование в джоне. Правда толку то, какой же дурак в 2011 году DES'ом пользуется, когда его можно сбрутфорсить чуть ли не за неделю на обычном писюке?! > Угу. Только у CLang'а их почему-то не было. Ну да, слив в 10 раз в smallpt - за эпикфэйл оптимизатора наверное не считается. > Ещё нет - но это уже больше экстенсивное развитие, при текущей скорости > прогрессирования LLVM-семейства вопрос нескольких лет. Коммунисты тоже так говорили. Целые 70 лет. Предлагая до этого погорбатиться за идею. > Если код был изначально написан с GCC-измами - что весьма и весьма > не редкость - то от патчей никуда не денешься. А некоторые гццизмы не так уж и плохи, хотя портабельность конечно понижают. > Факты таковы, что CLang _интереснее_ GCC. Если уж на то пошло, гнутый си лично мне интересен тем что поддерживает кучу архитектур, так что я могу освоив 1 набор компилера, линкера и сопутствующих утилит (читай binutils) программировать что угодно, от микроконтроллера размером с муравья, до ксеона размером с добрый кирпич. Ну а шланг как обычно уткнется на интелскую систему команд. Ну может арм еще, если эппла пропрет на аттракцион невиданной щедрости. Все остальное эпплу не нужно.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	45. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от Аноним (??) on 08-Ноя-11, 18:07
	> Коммунисты тоже так говорили. Целые 70 лет. Предлагая до этого погорбатиться за идею. А теперь так говорит Apple. И предлагает горбатиться не просто за идею, но еще и за коммерческий успех их продукции. Преимущества нового пути очевидны!
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	50. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 08-Ноя-11, 19:23
	>> Наезды на тормознутость CLang'а тоже делались на основе Phoronix'овских тестов. > Ну так и эти тесты ее показали. Единственное место где шланг себя > проявил - DES шифрование в джоне. Правда толку то, какой же > дурак в 2011 году DES'ом пользуется, когда его можно сбрутфорсить чуть > ли не за неделю на обычном писюке?! А по-вашему, кроме того, что было в тестах, никто ничего не компилирует? >> Угу. Только у CLang'а их почему-то не было. > Ну да, слив в 10 раз в smallpt - за эпикфэйл оптимизатора > наверное не считается. Речь была о регрессиях, а не о недоработках. Вы вообще разницу между понятиями чувствуете? >> Ещё нет - но это уже больше экстенсивное развитие, при текущей скорости >> прогрессирования LLVM-семейства вопрос нескольких лет. > Коммунисты тоже так говорили. Целые 70 лет. Предлагая до этого погорбатиться за > идею. Шикарный аргумент. Расходится с фактами, правда, но это ж детали. >> Если код был изначально написан с GCC-измами - что весьма и весьма >> не редкость - то от патчей никуда не денешься. > А некоторые гццизмы не так уж и плохи, хотя портабельность конечно понижают. Какие-то CLang и поддерживает. >> Факты таковы, что CLang _интереснее_ GCC. > Если уж на то пошло, гнутый си лично мне интересен тем что > поддерживает кучу архитектур, так что я могу освоив 1 набор компилера, > линкера и сопутствующих утилит (читай binutils) программировать что угодно, от микроконтроллера > размером с муравья, до ксеона размером с добрый кирпич. Ну а > шланг как обычно уткнется на интелскую систему команд. Ну может арм > еще, если эппла пропрет на аттракцион невиданной щедрости. Все остальное эпплу > не нужно. CLang можно уже сейчас использовать в ходе собственно разработки, которая ведётся почти вся на x86. Потому что он намного дружественнее к разработчику. И уже для конечного кода использовать GCC. Главное, что им будут пользоваться разработчики - не один так другой начнёт работать над поддержкой той или иной платформы... Linux, между прочим, изначально вообще был ни разу не портабельным за пределами x86, и ничего, как-то выкрутились. ;) Впрочем, если хотите жить днём сегодняшним и не интересоваться тем, что будет завтра, то пожалуйста. ;)
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	64. "Сравнение производительности результирующего кода GCC..."	+/–
	Сообщение от arisu (ok) on 09-Ноя-11, 23:41
	> Впрочем, если хотите жить днём сегодняшним и не интересоваться тем, что будет > завтра, то пожалуйста. ;) коммунизма завтра не будет. равно как и заруливания гцц шлангом. такие дела. изредка посматривать на шланг можно, но не более. так, игрушечка. интересная и пока бесполезная.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	65. "Сравнение производительности результирующего кода GCC..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Ноя-11, 01:48
	>> Впрочем, если хотите жить днём сегодняшним и не интересоваться тем, что будет >> завтра, то пожалуйста. ;) > коммунизма завтра не будет. равно как и заруливания гцц шлангом. такие дела. Лично я этого и не обещал. Ни один из них _полностью_ другой не заменит, во всяком случае, в обозримом будущем. > изредка посматривать на шланг можно, но не более. так, игрушечка. интересная и > пока бесполезная. Очень даже полезная, пусть и не каждому.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	74. "Сравнение производительности результирующего кода GCC..."	+/–
	Сообщение от Аноним (??) on 12-Ноя-11, 00:32
	> Очень даже полезная, пусть и не каждому. Не, товарищ, за идею твоя очередь 70 лет горбатиться. А мы в основном за результат. И да, GPL мне нравится в том числе и за результативность идеи. Оно делом доказало что это не просто красивая идея, но еще и эффективное средство коллаборации.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	78. "Сравнение производительности результирующего кода GCC..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 12-Ноя-11, 02:13
	>> Очень даже полезная, пусть и не каждому. > Не, товарищ, за идею твоя очередь 70 лет горбатиться. А мы в > основном за результат. И да, GPL мне нравится в том числе > и за результативность идеи. Оно делом доказало что это не просто > красивая идея, но еще и эффективное средство коллаборации. "Папа, ты это с кем сейчас разговаривал?" Какой "горбатиться", вас никто никуда не гонит. Причём тут вообще GPL?!
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	37. "Сравнение производительности результирующего кода GCC 4.6, L..."	+1 +/–
	Сообщение от Аноним (??) on 08-Ноя-11, 17:52
	> А теперь ждём извинений от крикунов, ещё в этом году здесь же, > на Опеннете, громко заявлявших, что CLang никогда не догонит GCC по > скорости конечного кода Так в большинстве тестов - отстает. А именно: 1) C-ray - на амд победил гцц, на интеле - шланг. Кому засчитать победу не ясно, в общем будем считать что 1:1. 2) Тест smallpt: нефутбольный счет 10:0 в пользу GCC. Шланг просрал на обоих платформах, при том на амд почти в 10 раз. На интеле "всего" в 5 раз :)) 3) 7zip: шланга вообще не вижу. Он не осилил собрать 7zip? Или чего? 4) OpenSSL: гцц победил, правда немного, но на обоих платформах. 5) В DES джона-риппера шланг конечно выиграл, только вот кого в 2011 году вообще интересует классический DES? DESом еще кто-то пользуется на свой зад? :) 6) На более актуальном MD5 шланг с треском слил. На обоих платформах. 7) И на Blowfish - тоже приличный слив у шланга. 8) И в тесте MAFFT - тоже слив. Итого: шланг серьезно победил разве что в никому не сдавшемся чемпионате по DES-шифрованию джоном-риппером. Это обалденный, непререкаемый EPIC WIN. Килограмм извинений прилагается.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	52. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 08-Ноя-11, 19:41
	>> А теперь ждём извинений от крикунов, ещё в этом году здесь же, >> на Опеннете, громко заявлявших, что CLang никогда не догонит GCC по >> скорости конечного кода > Так в большинстве тестов - отстает. А именно: > 1) C-ray - на амд победил гцц, на интеле - шланг. Кому > засчитать победу не ясно, в общем будем считать что 1:1. > 2) Тест smallpt: нефутбольный счет 10:0 в пользу GCC. Шланг просрал на > обоих платформах, при том на амд почти в 10 раз. На > интеле "всего" в 5 раз :)) Это тест на OpenMP. Сильно специфичная равно как и не устоявшаяся технология. Ну да не суть. > 3) 7zip: шланга вообще не вижу. Он не осилил собрать 7zip? Или > чего? Во-первых, только на одной из платформ; на другой паритет. Во-вторых, про отсутствие графика вообще вопрос к Форониксу. :) Результаты данного теста, стало быть, либо недействительны, либо опять 1:1. > 4) OpenSSL: гцц победил, правда немного, но на обоих платформах. Это "немного" в пределах погрешности измерений, так что ещё раз 1:1. > 5) В DES джона-риппера шланг конечно выиграл, только вот кого в 2011 > году вообще интересует классический DES? DESом еще кто-то пользуется на свой > зад? :) Это показатель того, как хорошо CLang компилирует целочисленные считалки. К слову, кое-где DES сейчас используется, в силу разных причин и не всегда по прямому назначению. :) > 6) На более актуальном MD5 шланг с треском слил. На обоих платформах. Эм. DES - это шифрование, MD5 - хеширование. Разные вещи. :) К тому же MD5 актуальным является не более, чем DES, ИМХО: его не раскритиковал только ленивый за предсказуемые коллизии. Надо было бы действительно SHA256, например, брать... И вообще проверять работу собственно функций, а не взломщика. Ну да не суть. Эта считалка у CLang получилась более тормозная, да. > 7) И на Blowfish - тоже приличный слив у шланга. Это тест тоже странный, на этот раз отсутствует Open64... > 8) И в тесте MAFFT - тоже слив. > Итого: шланг серьезно победил разве что в никому не сдавшемся чемпионате по > DES-шифрованию джоном-риппером. Это обалденный, непререкаемый EPIC WIN. Килограмм извинений > прилагается. Сравните с результатами где-то полугодовой давности. Тогда CLang из пяти тестов не слил только в одном. Сейчас этот показатель заметно улучшился. Вы понимаете, о чём речь?..
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	76. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от Аноним (??) on 12-Ноя-11, 01:07
	> Это тест на OpenMP. Сильно специфичная равно как и не устоявшаяся технология. > Ну да не суть. Как бы стандарт вроде вполне открытый и появился не вчера. Ряд программ им вполне себе пользуется. >> 3) 7zip: шланга вообще не вижу. Он не осилил собрать 7zip? Или чего? > Во-первых, только на одной из платформ; на другой паритет. > Во-вторых, про отсутствие графика вообще вопрос к Форониксу. :) > Результаты данного теста, стало быть, либо недействительны, либо опять 1:1. На графике почему-то нет шланга. А гцц есть. Видимо у шланга были какие-то проблемы? Там плюсы юзаются - может он ими подавился? >> 4) OpenSSL: гцц победил, правда немного, но на обоих платформах. > Это "немного" в пределах погрешности измерений, так что ещё раз 1:1. Фороникс отмечает погрешности на графиках, если они существенны и могут на что-то повлиять. Основы методик измерений в вузе или где там еще им кажется все-таки преподали вполне нормально. Поэтому если вы хотите записать 1:1 вы идете и находите у фороникса >> году вообще интересует классический DES? DESом еще кто-то пользуется на свой зад? :) > Это показатель того, как хорошо CLang компилирует целочисленные считалки. Тогда чего ради он не соптимизил соседние md5 и blowfish и проиграл там гцц? Они ничуть не менее целочисленные считалки. Ода шлангу не засчитывается по причине несоответствия наблюдаемым фактам. > К слову, кое-где DES сейчас используется, в силу разных причин и не > всегда по прямому назначению. :) Не вижу никакого повода использовать DES. Мало того что он не криптостоек по современным меркам, так он еще и сам по себе довольно тормозной по сравнению с другими. Хреновая криптостойкость в паре с хреновой скоростью - отличный повод забыть о алгоритме. Это один из бенчей фороникса, сакральный смысл которого мне не понятен. >> 6) На более актуальном MD5 шланг с треском слил. На обоих платформах. > Эм. DES - это шифрование, MD5 - хеширование. Разные вещи. :) Спасибо, капитан! Но имелось в виду что md5 еще используется, тогда как найти некрофилов не выбросивших DES - это придется сииииильно постараться. > К тому же MD5 актуальным является не более, чем DES, ИМХО: его > не раскритиковал только ленивый за предсказуемые коллизии. Да, для ряда применений он уже не фонтан. Тем не менее, данная атака имеет довольно ограниченное применение на практике. Поэтому в алгоритмах хеширования паролей с солью он живет и даже не настолько уж и плох. В смысле, подобрать коллизию к произвольному хешу по прежнему сложно. Актуален он лишь в том плане что по прежнему широко применяется в отличие от DES. > Надо было бы действительно SHA256, например, брать... Любители SHA-256 готовые удавиться за его скорость живут где-то там: https://en.bitcoin.it/wiki/Mining_Hardware_Comparison - ими забенчено все, вдоль и поперек, ибо бабло побеждает зло, поэтому забенчмаркано было все что вообще умеет считать. Правда вам не понравится вывод о том как быстрее всего считать sha-256, имхо. > И вообще проверять работу собственно функций, а не взломщика. У данного взломщика функции реализованы отдельно и достаточно оптимизированы. Правда кто ж нынче пароли на CPU ломает? GPU все-равно зарулит любой проц с космическим отрывом. > Ну да не суть. Эта считалка у CLang получилась более тормозная, да. При том это тоже целочисленная считалка. Поэтому ваша похвальба на предыдущем шаге совершенно не выглядит обоснованной. >> 7) И на Blowfish - тоже приличный слив у шланга. > Это тест тоже странный, на этот раз отсутствует Open64... Подозреваю что он облажался при компиляции алгоритма. Это он умеет. И опять шланг слил на целочисленной считалке. Поэтому похвальба за оптимизацию целочисленных вычислений как-то странно выглядит. >> прилагается. > Сравните с результатами где-то полугодовой давности. Тогда CLang из пяти тестов не > слил только в одном. Сейчас этот показатель заметно улучшился. Вы понимаете, о чём речь?.. Да, я понимаю. Выдача желаемого за действительного. По-моему, им обоим стоило бы поучиьтся у амдшного компилера в тесте C-ray. Если он люто победил в три раза обоих - значит оба явно недооптимизировали и им есть куда твикать оптимизацию еще.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	79. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 12-Ноя-11, 02:44
	>>> году вообще интересует классический DES? DESом еще кто-то пользуется на свой зад? :) >> Это показатель того, как хорошо CLang компилирует целочисленные считалки. > Тогда чего ради он не соптимизил соседние md5 и blowfish и проиграл > там гцц? Они ничуть не менее целочисленные считалки. Ода шлангу не > засчитывается по причине несоответствия наблюдаемым фактам. Какая ещё "ода"? Есть факты. Наблюдаемые, осязаемые. Часть этих фактов характеризует Clang плохо, часть - хорошо. И ещё есть тенденции. Тоже доступные любому, кто не пытается глаза закрыть с мантрой "нет компилятора кроме GCC". >> К слову, кое-где DES сейчас используется, в силу разных причин и не >> всегда по прямому назначению. :) > Не вижу никакого повода использовать DES. А я не вижу смысла в дальнейшей беседе. Новых аргументов по теме - ноль, только понты из серии "а я ещё про вот это читал!". Всего доброго.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	43. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от Аноним (??) on 08-Ноя-11, 18:03
	> А теперь ждём извинений от крикунов, ещё в этом году здесь же, > на Опеннете, громко заявлявших, что CLang никогда не догонит GCC по > скорости конечного кода из-за лицензии/сообщества/опыта/etc... (в том числе по результатам > форониксовских тестов, ага) Хм. А почему кто-то должен извиняться? Clang как оставал от gcc, так и отстает.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	56. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 08-Ноя-11, 21:33
	>> А теперь ждём извинений от крикунов, ещё в этом году здесь же, >> на Опеннете, громко заявлявших, что CLang никогда не догонит GCC по >> скорости конечного кода из-за лицензии/сообщества/опыта/etc... (в том числе по результатам >> форониксовских тестов, ага) > Хм. А почему кто-то должен извиняться? Clang как оставал от gcc, так > и отстает. Отстаёт заметно меньше, чем раньше. А кое-где и обгоняет.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	77. "Сравнение производительности результирующего кода GCC 4.6, L..."	+/–
	Сообщение от Аноним (??) on 12-Ноя-11, 01:08
	> А кое-где и обгоняет. Аж в целом DES джона-риппера. Нафиг не нужном, потому что в 2011 году DES уже почти все повыбросили. Это действительно бестолковый алгоритм.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

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

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