Разработчики дистрибутива OpenMandriva объявили (https://blog.openmandriva.org/en/2015/02/how-to-trace-a-cat-.../) о переходе по умолчанию на компилятор Clang, который будет использоваться вместо GCC для сборки пакетов в будущих выпусках дистрибутива. Также сообщается (https://blog.openmandriva.org/en/2015/02/openmandriva-to-hav.../) о подготовке нового инсталлятора, построенного с использованием фреймворка Calamares, в рамках которого разработчики различных дистрибутивов сообща пытаются подготовить (http://www.opennet.me/opennews/art.shtml?num=41582) универсальные средства для построения инсталляторов, не зависящие от конкретных дистрибутивов.URL: https://blog.openmandriva.org/en/2015/02/openmandriva-to-hav.../
Новость: http://www.opennet.me/opennews/art.shtml?num=41650
Закон не запрещает.
Закон не запрещает, но никаких преимуществ пользователям все это не дает. А вот недостатки будут - 10% пакетов в трэш, неспособность использовать OpenMP, который уже джва года обещают, ну и так далее.Так что как у юзеров этой мандалы упадет производительность в каком-нибудь imagemagic раза в 4 - известно кому надо за это сказать спасибо.
Зачем OpenMP, когда есть няшный GDC?
Из минусов:OpenMP (есть далеко не везде), чуть меньше производительность (на самомо деле в целом не сильно меньше)
Из плюсов:
Меньше нагрузка на сборочную инфраструктуру (бістрее компилирует), гораздо лучше средства диагностики.
Из обьективного:
Шланг достаточно активно догоняет GCC в скорости получаемого кода. Приблизительный паритет (пусть с минимальным перевесом GCC можно ждать в обозрииомом будущем).
Из искреннего интереса спрашиваю:> (на самомо деле в целом не сильно меньше)
> Шланг достаточно активно догоняет GCC в скорости получаемого кода.А можно ссылочку? Например тут всё как-то не так [1]
[1] http://www.phoronix.com/scan.php?page=article&item=gcc49_com...
И про это тоже ссылку, пожалуйста:
> гораздо лучше средства диагностики.
> [1] http://www.phoronix.com/scan.php?page=article&item=gcc49_com...CLang: 2,3,4,5
GCC: 6,8,9,11
паритет в 12,7,10Тест #1 хуже без OpenMP. Что тут "не так"? По-моему именно то, что тебе и сказали.
>> [1] http://www.phoronix.com/scan.php?page=article&item=gcc49_com...
> CLang: 2,3,4,5
> GCC: 6,8,9,11
> паритет в 12,7,10
> Тест #1 хуже без OpenMP. Что тут "не так"? По-моему именно то,
> что тебе и сказали.Ну, например, рассмотрим вот это:
>> (на самомо деле в целом не сильно меньше)
Все тесты на производительность приложений из статьи (без исключений):
- [ 1] Производительность GraphicsMagick: clang в 2 раза медленнее.
- [ 2] Производительность Himeno Poisson Pressure Solver: gcc на 6.5% медленнее.
- [ 6] Производительность C-Ray: clang в 1.5 раза медленнее.
- [ 7] Производительность ebizzy: одинаковая.
- [ 8] Производительность FLAC audio encoding: clang на 14% медленнее.
- [ 9] Производительность With MP3 encoding via LAME: сlang на 24% медленнее.
- [10] Производительность ffmpeg: одинаковая, ибо упичкан ассемблерным кодом (и поэтому не столь сильно зависит от особенностей компилятора).
- [11] Hierarchical Integration test: clang в 1.5 раза медленнее.
- [12] Производительность Apache web-server: одинаковаяЭто вовсе не «не сильно меньше».
> CLang: 2,3,4,5
В тесте №2 выигрыш крайне мал в сравнении с проигрышами в других тестах (см. выше). А тесты №3, №4 и №5 были не на производительность скомпилированной программы, а на скорость компиляции.
То есть я бы скорее написал:
GCC: 1,6,8,9,11
CLang: 2(?)
Draw: 2(?),7,10(?),12
а разве в кланг ещё не впилили опенмп? я чёт на полгода из темы выпал вроде там уже всё почти готово было..
>более качественная генерация и оптимизация объектного кода.А где цыфарки посмотреть? А то я в сказки не верю.
в поисковике: "Clang 3.4 Performance Very Strong Against GCC 4.9"Только на поверку она не стронг местами.
> в поисковике: "Clang 3.4 Performance Very Strong Against GCC 4.9"
> Только на поверку она не стронг местами.Лучшие традиции желтой прессы, да.
>Лучшие традиции желтой прессы, да.Не знаю о чём вы, но в этих ваших интернетах более менее только он делает тесты.
> Не знаю о чём вы, но в этих ваших интернетах более менее
> только он делает тесты.Не знаю какие там тесты шланг делает более-менее но во всех программах использующих OpenMP он продувает GCC по числу ядер проца. А просто потому что шланг не умеет OpenMP.
Что, собственно говоря, он и подтвердил в тесте сравнивая GCC 4.8 и Clang 3.3
> Clang 3.3Это же подтвердилось в 3.4 и 3.5. Там уже джва года завтраками кормят про OpenMP. Но воз и ныне там.
>> Не знаю о чём вы, но в этих ваших интернетах более менее
>> только он делает тесты.
> Не знаю какие там тесты шланг делает более-менее но во всех программах
> использующих OpenMPТак назовите эти программы. Может их с гулькин нос наберётся и не интересны они большинству.
> он продувает GCC по числу ядер проца. А просто потому что шланг не умеет OpenMP.
Откуда вы это берёте?
///---http://llvm.org/releases/3.5.0/tools/clang/docs/ReleaseNotes...
Clang 3.5 now has parsing and semantic-analysis support for all OpenMP 3.1 pragmas (except atomics and ordered). LLVM’s OpenMP runtime library, originally developed by Intel, has been modified to work on ARM, PowerPC, as well as X86. Code generation support is minimal at this point and will continue to be developed for 3.6, along with the rest of OpenMP 3.1. Support for OpenMP 4.0 features, such as SIMD and target accelerator directives, is also in progress. Contributors to this work include AMD, Argonne National Lab., IBM, Intel, Texas Instruments, University of Houston and many others.
---///
> Так назовите эти программы. Может их с гулькин нос наберётся и не
> интересны они большинству.Ну вон imagemagic, например. Во всех бенчах рвет шланга в хламину. И да, знаешь, втыкать на 8-ядернике в почти 8 раз дольше на процессинг картинки - совсем не здорово, имхо.
Потреб-дям он конечно не интересен, им вообще интересно киношку смотреть да птичек метать, попутно запостив каой-нибудь крап в фэйсбук. Так что им вообще планшетика с андроидом - выше крыши.
> Откуда вы это берёте?
Да вон на форониксе бенчи например
> Instruments, University of Houston and many others.
Маркетинговый булшит это круто. А теперь айда сделать gcc в бенчмарках. Хренли мне толку с университета Хьюстона если это нечто сдриснет gcc в несклько раз на обработке картинки?
>> Так назовите эти программы. Может их с гулькин нос наберётся и не
>> интересны они большинству.
> Ну вон imagemagic, например.Нет такого приложения. Есть ImageMagick. Из этого я делаю вывод, что ты сам не используешь его.
> Во всех бенчах рвет шланга в хламину.
В каких "во всех"?
> И
> да, знаешь, втыкать на 8-ядернике в почти 8 раз дольше на
> процессинг картинки - совсем не здорово, имхо.Вот здесь: http://www.freshports.org/graphics/ImageMagick/
порт по умолчанию собирается с опцией "THREADS=on: Threading support" и с выключенной опцией "OPENMP=off: Parallel processing support via OpenMP". То есть нам предлагается на выбор либо работать с использованием стандартной многопоточной модели, либо к тому же задействовать OpenMP — и то и другое будет собираться Clang:
http://svnweb.freebsd.org/ports/head/graphics/ImageMagick/Ma....if ${_IMAGEMAGICK_THREADS} == "yes"
CONFIGURE_ARGS+= --with-threads
CONFIGURE_ENV+= PTHREAD_CFLAGS="${PTHREAD_CFLAGS}" \
PTHREAD_LIBS="${PTHREAD_LIBS}"
LDFLAGS+= ${PTHREAD_LIBS}
.else
CONFIGURE_ARGS+= --without-threads
_IMAGEMAGICK_THREADS=no
.endif# OpenMP
.if ${PORT_OPTIONS:MOPENMP}
. if ${_IMAGEMAGICK_THREADS} == "no"
IGNORE=OpenMP requires threads${_IMAGEMAGICK_THREADS_IGNORE_MSG}
. else
CONFIGURE_ARGS+= --enable-openmp
USES+= compiler:openmp
. endif
.else
CONFIGURE_ARGS+= --disable-openmp
.endifСпециально для тебя собрал:
% pkg info ImageMagick-6.9.0.4,1
ImageMagick-6.9.0.4,1
Name : ImageMagick
Version : 6.9.0.4,1
Installed on : Wed Feb 11 14:18:57 MSK 2015
Origin : graphics/ImageMagick
Architecture : freebsd:10:x86:64
Prefix : /usr/local
Categories : perl5 graphics
Licenses : APACHE20
Maintainer : kwm@FreeBSD.org
WWW : http://www.ImageMagick.org/
Comment : Image processing tools
Options :
16BIT_PIXEL : on
BZIP2 : on
DJVU : off
DOCS : on
FFTW : on
FONTCONFIG : on
FPX : on
FREETYPE : on
GRAPHVIZ : off
GSLIB : off
HDRI : off
JBIG : on
JPEG : on
JPEG2000 : on
LCMS2 : on
LQR : on
LZMA : on
MODULES : on
OPENEXR : off
OPENMP : on
PANGO : off
PDF : on
PERL : on
PNG : on
SVG : on
TESTS : off
THREADS : on
TIFF : on
WEBP : on
WMF : on
X11 : on% cc --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
Thread model: posix>> Откуда вы это берёте?
> Да вон на форониксе бенчи напримерДавай ссылки, чо.
>> Instruments, University of Houston and many others.
> Маркетинговый булшит это круто. А теперь айда сделать gcc в бенчмарках. Хренли
> мне толку с университета Хьюстона если это нечто сдриснет gcc в
> несклько раз на обработке картинки?А давай. Хотелось бы увидеть твои выхлопы терминальных запусков приложений, а потом проверить у себя.
При активированной опции "OPENMP" в зависимостях оказывается GCC 4.8.4 (порт lang/gcc). Так что эта фича не для Clang'а.
Там где обработка картинок ImageMagick-ом будет существенно нагружть проц(ну например на каком-нить вебсервисе), все-равно придется делать какую-нибудь очередь по их обработке, и, вероятно, обрабатывать несколько картинок параллельно. 1 там ядро или 24 будет он использовать в этом кейсе вообще не имеет значения.
> Только на поверку она не стронг местами.А если программа использует OpenMP - то совсем-совсем-не-стронг.
Да он и без OpenMP нифига не стронг.
> А где цыфарки посмотреть? А то я в сказки не верю.Какие циферки? Сказано же - _качественная_.
Был же новость об этом? Полгода или год назад.
Здесь не было. https://www.linux.org.ru/news/linux-general/11016773
> ускорение процесса компиляцииНа что на что, а на это юзерам бинарного дистра пох. А вот то, что некоторые прогарммы теперь станут медленней работать нет.
> а на это юзерам бинарного дистра пох.нет, это OpenMandriva пох на юзеров
Из "преимуществ" понятно только ускорение компиляции. Остальное - либо чушь (вроде более качественного кода) либо (диагностика) касается разработчиков, а не маинтайнеров. Чай, не дебиан, чтобы вагон своих патчей накладывать.
> чушь (вроде более качественного кода)Оптимальный код можно написать только мозгами на ассемблере, компилятор лишь стремится к этому через набор правил трансляции. Ничто не мешает усовершенствовать компилятор, избавившись, например, от поддержки "бородатых" архитектур. Вполне возможно, что Крэнг заменит gcc для "попсовых" x86, x64 или arm64; а gcc останется как "комбайн" для кросс-компиляции на кофемолки.
Вы будете смеяться, но уже очень мало кто пишет на ассемблере код, который быстрее выдаваемого кодогенераторами современных компиляторов. Это раньше было просто, а сейчас человеку трудно учесть ту массу факторов, которую компилятор учитывает постоянно, процессоры стали очень уж сложно устроены.Да, когда-то было известно, какая команда сколько тактов выполняется. Потом пошли кеширования памяти, предсказания переходов и тому подобное. Постепенно всё это зашло так далеко, что среднему разработчику, пишущему на ассемблере, в большинстве случаев не угнаться за кодогенератором, учитывающим кучу факторов. Так что ассемблерные куски имеют смысл либо при очень специфичных низкоуровневых операциях, либо если точно известно, что в конкретном месте компилятор не справился, либо для простеньких микроконтроллеров.
Кодогенераты нам подарены инопланетянами? Или все-таки написаны людьми, к-е смогли угнаться за кодогенераторами и написать кодогенераторы?
Есть разница между описанием правил и постоянном следовании им. Так вот, разработчики компиляторов описали правила генерации кода (наряду с массой алгоритмов высокоуровневой оптимизации, о которых большинство даже не слышало).
Шахматные программы тоже создаются людьми, как и компьютеры. Но лучшие шахматные программы, запущенные на современных компьютерах, давно сильнее людей, даже чемпионов.А ещё подъёмные краны, созданные людьми, поднимают вес куда больший, чем человек. :)
Да, лично у меня перестало хватать мозгов на качественную оптимизацию ещё где-то начиная с Пентиума, может, с MMX. Но, в принципе, я знаком с острозаточенными людьми, которые и в 2010-ом уделывали компиляторы в разы, правда, не на generic x86 & Co, а на гораздо более специфичных архитектурах.
Это в первую очередь из-за того, что компиляторы под "непопсовые" архитектуры мало кто сильно оптимизирует.
> правда, не на generic x86 & Co, а на гораздо более
> специфичных архитектурах.И затачивают не массовые кодогенераторы меньше, и сама архитектура проще. Для старого доброго Atmel AVR и я компилятор обычно уделывал, даже в 2011 году. Но AVR, конечно, уж совсем тупой, это крайность.
Увы (или к счастью, скорее даже к счастью), чем дальше, тем будет тяжелее. Эра, когда люди писали на ассемблере, уходит. В 99% случаев ассемблер теперь нужен программисту только при отладке. Во всяком случае, на x86 и подобных.
> В 99% случаев ассемблер теперь нужен программисту только при отладке.А из-за того что по-настоящему хорошо ассемблер уже мало кто знает, этот 1% случаев приносит мне 99% денег.
Что ж, быть экзотическим специалистом неплохо. До тех пор, пока эта экзотика востребована. Думаю, в редких случаях ещё будет довольно долго, так что от души желаю хорошего куска хлеба с маслом. :) Я сам до сих пор неравнодушен к ассемблерам, хотя очень давно не пишу на них: первая любовь не забывается. :)
То-то я смотрю, что в колибриОС программы запускаются раньше, чем я кнопку мыши отпускаю :)
Почему с каждой новой версией компиляторов на выходе программы становятся все тяжелее и тяжелее, ведь кодогенераторы лучше людей, пишущих на ассемблере?:)
Это никак не относится к кодогенерации. В KolibriOS можно писать на си, и программы точно так же будут быстро запускаться.
> То-то я смотрю, что в колибриОС программы запускаютсяВсе три?
https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
>/emacs-devel/2015-02/msg00457.htmlwe r the esr^Wllvm^Wapple surrender all yor shields
> более качественная генерация и оптимизация объектного кода.ORLY?
>> более качественная генерация и оптимизация объектного кода.
> ORLY?Сектанты же. А RMS просто спросил!1!
""[...]the LLVM people are fanatical, absolutely fanatical, about refactoring and keeping their architecture clean. The whole thing is kept extremely modular, very easily modified, very well documented. LLVM *is* clean. It is, in fact, architecturally beautiful. I wish it wasn't written in C++, and[...] -- https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
забавно наблюдать как Штольману объясняют, что писать lldb гораздо проще чем GDB, потому что у LLVM модульная архитектура :)
а толку метать бисер? это тело знает только что он бог и gcc единственный компилятор. Если бы у него хватило понимания - то давно сделал бы export AST для сторонних приложений.
> а толку метать бисер? это тело знает только что он бог и
> gcc единственный компилятор. Если бы у него хватило понимания - тоЕсли бы понимания хватило у тебя, у "нас" _давно были бы egcs II и XEmacs II.
>> а толку метать бисер? это тело знает только что он бог и
>> gcc единственный компилятор. Если бы у него хватило понимания - то
> Если бы понимания хватило у тебя, у "нас" _давно были бы egcs
> II и XEmacs II.А лично ты что нам подарил, прости?
>>> это тело знает
>>>Если бы у него хватило понимания - то
>> Если бы понимания хватило у тебя, у "нас"
> А лично ты что нам подарил, прости?Взгляд в зеркало на собственное хамство, конечно. Пользуйтесь!
Ренегаты! :)
ядро тоже можно clang-ом?
http://llvm.linuxfoundation.org/index.php/Main_PageНо у меня месяца три назад не вышло, хотел ради интереса попробовать собрать, не собралось.
Не нужно собирают не нужным.