Компания AMD опубликовала (https://www.reddit.com/r/Amd/comments/6be5qf/amd_optimizing_... первый выпуск компилятора AOCC (http://developer.amd.com/tools-and-sdks/cpu-development/amd-... (AMD Optimizing C/C++ Compiler), построенного на базе LLVM 4.0 и включающего дополнительные улучшения и оптимизации для 17 семейства процессоров AMD на базе микроархитектуры Zen (https://ru.wikipedia.org/wiki/AMD_Ryzen), в частности для уже выпускаемых процессоров AMD Ryzen. В компилятор также внесены общие улучшения, связанные с векторизацией, генерацией кода, высокоуровневой оптимизацией, межпроцедурным анализом и преобразованием циклов.
Компилятор доступен для 32- и 64-разрядных Linux-систем. Предлагаемые для загрузки исполняемые файлы протестированы в RHEL 7.2, SLES 12 SP1 и Ubuntu 16.04 LTS, но в общем виде пригодны для запуска на любых системах с Glibc 2.17 и более новых выпусках. AOCC пока распространяется только в бинарном виде и требует принятия EULA-соглашения.
URL: https://www.reddit.com/r/Amd/comments/6be5qf/amd_optimizing_.../
Новость: http://www.opennet.me/opennews/art.shtml?num=46575
Ладно EULA, но что в нем такого необычного в этом компиляторе, что они сами его развивают?
>на базе LLVMНе сами, а на базе Шланга. Они лишь прикрутили нюансы, связанные со своими новыми процами.
Сам я пока GCC использую и Шланг даже палочкой не тыкал, но как бы не пришлось переходить.
БСДшники, говорят, уже собирают свою систему шлангом и всё работает. А тут, видишь, новые оптимизации не под GCC делаются.
Стрёмно лишь одно -- лицензия. Шланг позволяет пихать модули-блобы, которые будут компилировать непонятно что и непонятно как. Но корпорации любят блобы. И по идеологическим причинам и им банально так проще.
Сегодня всё хорошо, а завтра без блоба за 7.62$ хрен ты соберёшь программу без зонда-бекдора. Так что пока GCC.
Вот только по тестам фороникса он не намного лучше mainline llvm 4.0/gcc 6 - https://www.phoronix.com/scan.php?page=article&item=amd-ryze...
> Сам я пока GCC использую и Шланг даже палочкой не тыкал, но
> как бы не пришлось переходить.Не придется. GCC живее всех живых, особенно после недавнего пересмотра подхода к разработке. Нынче он тоже топает семимильными шагами, и не только в нумерации. Многое и ломают, правда, к сожалению.
> БСДшники, говорят, уже собирают свою систему шлангом и всё работает.
Они к этому очень долго шли, причем процесс был двухсторонний - точился и шланг под BSD, точилась и BSD под шланг. Полноценную сборку ядра Linux шланг до сих пор сделать не в состоянии. Собирается какая-то часть, вроде бы даже запускается и работает, но часть эта очень маленькая.
> А тут, видишь, новые оптимизации не под GCC делаются.
По очевидной причине - лицензия. В GCC все свои наработки открывать придется, а тут делай что хочешь и никто тебе не указ.
> Не придется. GCC живее всех живых, особенно после недавнего пересмотра подхода к разработке. Нынче он тоже топает семимильными шагами, и не только в нумерации.Проект на самом деле стал настолько сильно большим что надо усовершенствовать не только подход к разработке но и методы. Это нужно сделать.
> Многое и ломают, правда, к сожалению.
Плохо если ломают необдуманно. А если ломают ради развития, то это всегда хорошо, хоть и не совсем приятно.
> По очевидной причине - лицензия. В GCC все свои наработки открывать придется, а тут делай что хочешь и никто тебе не указ.
Всегда были и будут копирасты и даже простые обыватели которые хотят "засадить пользователю блоб" или "насадить на eula'у". Чтобы не потерять ориентиры, надо просто вспомнить из-за чего появился GPL и GNU. Если бы не GPL то Linux никогда не стал бы таким каким он стал.
> Всегда были и будут копирасты и даже простые обыватели которые хотят "засадить
> пользователю блоб" или "насадить на eula'у".Уже было с Darwin'ом, кстати - закрыли, потом поняли, что фигня получается, открыли обратно. В результате только получили репутацию ненадёжных людей.
> Чтобы не потерять ориентиры, надо просто вспомнить из-за чего появился GPL и GNU.
Кмк, все заинтересованные это знают. GPL в некотором смысле частично потеряла актуальность - сообщество уже, в общем, отдрессировано жить по коммунистическим правилам. Это же просто удобный инструмент для того, чтобы проект не закрыли, но если его разрабатывают более-менее вменяемые люди и не делают закрытые форки, то какая разница - GPL/BSD.
Да, в 90-х GPL была необходимостью, а сейчас, слава богу, это просто предохранитель. А "в мире Полдня" она вообще будет не нужна. :-)
> Если бы не GPL то Linux никогда не стал бы таким каким он стал.Дык.
Так себе сообщество отдрессировано - на ПК ещё ладно, а шаг в сторону на тот же андроид - на одно открытое приложение на любую тематику - сотня закрытых.Производители не-ПК тоже как-то не особо готовы открытые драйверы давать - сплошь блоб на подписанном блобе. В серверных делах - там ситуация получше, да.
Я говорю про системщиков. Всё очень просто - есть ИТшный коммунистический локус, затравку к которому сделал дедушка Столлман, есть капиталистический мир. Граница между локусом и внешним миром размыта, поэтому чем ближе сюда, тем больше вероятность, что софт будет открыт, чем ближе туда - тем меньше вероятность.Компиляторы находятся практически в центре локуса, поэтому шансы, что что-то закрытое в области компиляторов не сдохнет, практически 0-ые.
> Уже было с Darwin'ом, кстати - закрыли, потом поняли, что фигня получается, открыли обратно. В результате только получили репутацию ненадёжных людей.Со временем закрытые технологии либо пропадают без вести либо переходят в существование в открытом виде (это может быть независимая реализация). Все везде и всегда так, даже патенты выходят сроком и дальше возможно свободное использование.
> Кмк, все заинтересованные это знают. GPL в некотором смысле частично потеряла актуальность - сообщество уже, в общем, отдрессировано жить по коммунистическим правилам. Это же просто удобный инструмент для того, чтобы проект не закрыли, но если его разрабатывают более-менее вменяемые люди и не делают закрытые форки, то какая разница - GPL/BSD.
Вам кажется не верно. Вы несколько наивны/инфантильны. GPL - это защитник который не только защищает проект от закрытия кода, но и привлекает независимых разработчиков к содействию которые не пришли бы в проект если бы была возможность его закрытия. Именно из-за этого явления Linux выстрелил, т.к. это был серьезным GPL-ядром в свое время. Я тоже например никогда не буду безвозмездно помогать ни словом, ни делом, ни деньгами не GPL проектам.
> Да, в 90-х GPL была необходимостью, а сейчас, слава богу, это просто предохранитель. А "в мире Полдня" она вообще будет не нужна. :-)
Без GPL проект растащат также как растащили общественный цветмет и чермет которые лежал свободно пока существовал СССР. GPL как бы гарантирует существованию проекта независимо от компании и частных лиц. Вот развалилась компания, а код остался.
> Со временем закрытые технологии либо пропадают без вести либо переходят в существование
> в открытом виде (это может быть независимая реализация).Да, дохнет закрытое, в корчах, если находится в коммунистическом локусе. Туда ему и дорога.
> Вам кажется не верно. Вы несколько наивны/инфантильны. GPL - это защитник который
> не только защищает проект от закрытия кода, но и привлекает независимых
> разработчиков к содействию которые не пришли бы в проект если бы
> была возможность его закрытия.Ясен пень. Но в 90-х это было безумно важно, а сейчас - накал в системном софте уже подспал. В прикладухе, на границе коммунистического локуса - да, если мы делаем софт вроде ОpenOffice, его нужно писать под GPL. Никаких BSD/MIT ни в коем случае - растащат.
Но компиляторы в центре локуса - там всем очевидно, что утащив в угол только проиграешь, причём быстро. Будешь тянуть свои патчи, подстраиваясь под быстроменяющийся upstream и тратить гору сил впустую.
> Я тоже например никогда не буду безвозмездно помогать ни словом,
> ни делом, ни деньгами не GPL проектам.Хороший подход.
> Без GPL проект растащат также как растащили общественный цветмет и чермет которые
> лежал свободно пока существовал СССР. GPL как бы гарантирует существованию проекта
> независимо от компании и частных лиц. Вот развалилась компания, а код
> остался.Нет, GPL - это не панацея. Это просто некоторый инструмент, который тоже можно обойти. Да, выкручивание рук именно для того, чтобы предотвратить классическую теор-игровую ситуацию "растаскивания СССР на цветмет". Да, оно полезно, но это лишь один из механизмов.
вау.
а на вашей шкуре ещё есть место для рекламы?
> Я прожил в СССР достаточно, чтобы моя шкура запомнила это навсегда. А вы сколько там прожили?В конце СССРа было практически включено "чёрное излучение". Как говорил Странник - 20% остаются шизофрениками.
Моя шкура это тоже запомнила навсегда, а особенно мозги, которые получили превосходное техническое образование.
Что значит было....
> Я прожил в СССР достаточно, чтобы моя шкура запомнила это навсегда. А вы сколько там прожили?Не важно сколько я там прожил, важно какой информацией и какого уровня я обладаю. У вас заявления уровня подъездного пенсионера. Мне с вами разговаривать просто не о чем.
>если мы делаем софт вроде ОpenOffice, его нужно писать под GPL.Да вот только ОpenOffice - сдох :-)
>Никаких BSD/MIT ни в коем случае - растащат.
Ути -пуси! LibreOffice выросший на костях ОpenOffice, в вполне бодрвый ВНЕЗАПНО под:
License: MPLv2.0 (secondary license GPL, LGPLv3+ or Apache License 2.0)[7]A MPL ~= MIT ... впрочем над больными смеяться - грех, за сим расходимся ....
> Я тоже например никогда не буду безвозмездно помогать ни словом, ни делом, ни деньгами не GPL проектам.А пользоваться такими проектами тоже не будете? Или ваши принципы включаются только когда вы им можете чем-то помочь?
> Без GPL проект растащат также как растащили общественный цветмет и чермет которые лежал свободно пока существовал СССР.
Не перестаю удивляться, что разницы между объектами физического мира и цифрового не понимают даже некоторые айтишники!
> А пользоваться такими проектами тоже не будете? Или ваши принципы включаются только когда вы им можете чем-то помочь?Так я и не пользую BSD, перестал как разобрался в тонкостях лицензии и современных веяниях копирастии.
> Не перестаю удивляться, что разницы между объектами физического мира и цифрового не понимают даже некоторые айтишники!
Я давно не удивляюсь ограниченности людей которые не видят за аналогиями образы.
> Так я и не пользую BSD, перестал как разобрался в тонкостях лицензии и современных веяниях копирастии.Так GPL и есть скрытый проприетар, а копирастия - в любой лицензии, ибо (С) никто не может отменить по закону.
> Да, в 90-х GPL была необходимостью, а сейчас, слава богу, это просто предохранитель. А "в мире Полдня" она вообще будет не нужна. :-)А ты оптимист... Но завидую оптимизму, да..
> Проект на самом деле стал настолько сильно большим что надо усовершенствовать не
> только подход к разработке но и методы. Это нужно сделать.Кстати, про методы - давно пора сделать специальную социальную сеть, наподобие GitHub'а, но распределённую. Чтобы убрать единую точку отказа в виде GitHub.
> Кстати, про методы - давно пора сделать специальную социальную сеть, наподобие GitHub'а, но распределённую. Чтобы убрать единую точку отказа в виде GitHub.Вообще не о том. Весь Интернет распределенный - создайте независимо от github репозитории, и вот у вас уже пример как "убрать единую точку отказа в виде GitHub".
> Вообще не о том. Весь Интернет распределенный - создайте независимо от github
> репозитории, и вот у вас уже пример как "убрать единую точку
> отказа в виде GitHub".Вот уж точно семь мудрецов не прокомментируют.
> Полноценную сборку ядра Linux шланг до сих пор сделать не в состоянии. Собирается какая-то часть, вроде бы даже запускается и работает, но часть эта очень маленькая.Эти ребята с тобой не согласны https://www.openmandriva.org/?lang=en Если и есть нюансы, то незначительные.
Нюансы есть, и они значительные. В OpenMandriva только юзерспейс собирается Шлангом, и то не весь. Ядро собирается GCC.
Вот проект поддержки сборки ядра шлангом:
http://llvm.linuxfoundation.org/index.php/Main_Page
Там куча патчей для ядра (патчи для шланга отдельно не выкладывают, поскольку их принимают в основную ветку) плюс даже при этом собирается не все, не для всех архитектур, не самой актуальной версии и с зависимостями от кусков GCC. Я не пеняю шлангу - они играют в догоняющих - но просто говорю, что о сборке им ядра можно говорить пока только в контексте развития самого шланга.
> По очевидной причине - лицензия. В GCC все свои наработки открывать придется, а тут делай что хочешь и никто тебе не указ.Мы все помним как забыли linking exceptions в gcc. Помним...
Ваши проблемы, никогда не зацикливайтесь на событиях прошлого.
> Мы все помним как забыли linking exceptions в gcc. Помним...Ну бросьте в них камень первым.
>> По очевидной причине - лицензия. В GCC все свои наработки// Странно, да? Чегой-то они-то сами всё своё открыли? Не понять этого _любителям_ _закрывать_, да.
> Мы все помним как забыли linking exceptions в gcc. Помним...
Памятливый?? http://www.opennet.me/openforum/vsluhforumID3/107145.html#61
Канделябром.
> Не придется. GCC живее всех живых, особенно после недавнего пересмотра подхода к разработке.Придётся! А иначе без графики останетесь.
make LLVM only a BUILD_DEPEND for mesa-libs, which needs it to build EGL
Изя, твое мнение никого не интересует.
Есть ещё такой вопрос: почему бы просто не выпаривая разработчикам мозги своими собственными компиляторами под каждую платформу взять, и закоммитить это всё в оригинальный шланг?
> Есть ещё такой вопрос: почему бы просто не выпаривая разработчикам мозги своими
> собственными компиляторами под каждую платформу взять, и закоммитить это всё в
> оригинальный шланг?Вряд ли в шланге обрадуются улучшайзерам типа
if (!cpuid_is("AuthenticAMD")) { random_sleep = 1; slow_and_crappy_fallback_code = 1;} /* утированно конечно, но в каждой шутке ... */
>> Есть ещё такой вопрос: почему бы просто не выпаривая разработчикам мозги своими
>> собственными компиляторами под каждую платформу взять, и закоммитить это всё в
>> оригинальный шланг?
> Вряд ли в шланге обрадуются улучшайзерам типа
>
> if (!cpuid_is("AuthenticAMD")) { random_sleep = 1; slow_and_crappy_fallback_code = 1;}
> /* утированно конечно, но в каждой шутке ... */Зря смеетесь, icc так и работает - внутри бинарника два варианта кода: оптимизированный для интелов и обычный generic - для остальных.
> Зря смеетесь, icc так и работает - внутри бинарника два варианта кода:
> оптимизированный для интелов и обычный generic - для остальных.Не обычный, а деоптимизированный - вроде бы писали что через *эмуляцию* SSE команд...
(сегодня как раз читал, там ещё представитель Intel отбрехивался в глаза что то такой удобный им всеголишь типа баг и т.п.)
> без блоба за 7.62$ хрен ты соберёшь программу без зонда-бекдораТут что-то не так с логикой.
Как человек, перекомпилявший Gentoo Clang'ом, могу сказать, что позиции GCC всё ещё очень сильны.
Некоторые проги не собираются Clang'ом, если либы-зависимости собраны Clang'ом. Например, libraw и libsndfile собранные Clang'ом, не дают собраться gwenview и kde-frameworks.
Про то, что часть пакетов не компилируется Clang'ом в принципе - хрен с ним, а вот то, что после перекомпиляции отвалился МФУ, перестал работать imagemagick и стали происходить разные странности - это да.
К слову, пока устанавливал обратно собранные GCC пакеты - всё решилось ещё в процессе.
> Как человек, перекомпилявший Gentoo Clang'ом, могу сказать, что позиции GCC всё ещё
> очень сильны.
> Некоторые проги не собираются Clang'ом, если либы-зависимости собраны Clang'ом. Например,
> libraw и libsndfile собранные Clang'ом, не дают собраться gwenview и kde-frameworks.
> Про то, что часть пакетов не компилируется Clang'ом в принципе - хрен
> с ним, а вот то, что после перекомпиляции отвалился МФУ, перестал
> работать imagemagick и стали происходить разные странности - это да.
> К слову, пока устанавливал обратно собранные GCC пакеты - всё решилось ещё
> в процессе.Все странности — к неродному для LLVM компоновщику GNU LD, который связывает объектный x86_64 код. Как только LLD будет готов, вот тогда и заживём.
> Все странности — к неродному для LLVM компоновщику GNU LD, который связывает
> объектный x86_64 код. Как только LLD будет готов, вот тогда и
> заживём.Возможно. Я делал по ману, который включал использование Gold, может, где-то накосячил.
>Как только LLD будет готов, вот тогда и заживём.Святая простота ...
В коде вокруг столько GCC-зЪмоффф за 10 лет не вычистить. У бсд-шнегов за такое в базе давали по рукам, вот они и перешли. Ядро линукс так перевести - это не птице до середины днепра :-\ Да и интересанты - кто? А никто, нет таких.
> Некоторые проги не собираются Clang'ом, если либы-зависимости собраны Clang'ом. Например,
> libraw и libsndfile собранные Clang'ом, не дают собраться gwenview и kde-frameworks.
% strings -a /usr/local/lib/libraw.so.16.0.0|grep clang
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)
% strings -a /usr/local/lib/libsndfile.so.1.0.28|grep clang
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)
% strings -a /usr/local/bin/gwenview|grep clang
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)
> перестал работать imagemagick и стали происходить разные странности - это да.
% strings -a /usr/local/lib/libMagick++-6.so.6.0.0|grep clang
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)
% strings -a /usr/local/bin/identify|grep clang
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)
И?
Gentoo и FreeBSD, к слову, разные вещи.
> И?
> Gentoo и FreeBSD, к слову, разные вещи.Теплое и мягкое тоже.
Т.е. вам это совсем не говорит о том, что проблема может быть, хотя бы в некоторых случаях, немножечко не совсем в Clang-е? Яснопонятно.
Я где-то писал разве, что "проблема *в* Clang'е"?
Я отписал выше свой опыт "как есть", а кто-то просто увидел то, что хотел увидеть.
> Как человек, перекомпилявший Gentoo Clang'ом, могу сказать, что позиции GCC всё ещё
> очень сильны.Как человек, прочитавший ваш и прочих энтузиастов программы эппла "пересоберём всё-всё, пятилетку в три года, наш труд на благо родного эппле" отчёты об пересборках, могу сказать, что позиции clang-а всё ещё очень слабы.
> Некоторые проги не собираются Clang'ом, если либы-зависимости собраны Clang'ом. Например,
> libraw и libsndfile собранные Clang'ом, не дают собраться gwenview и kde-frameworks.Ваши конвульсии вызывают повсеместное недоумение -- могут же люди, ай да молодцы же.
> Про то, что часть пакетов не компилируется Clang'ом в принципе - хрен
> с ним, а вот то, что после перекомпиляции отвалился МФУ, перестал
> работать imagemagick и стали происходить разные странности - это да.Аудитория в восхищении. И всё ради чего? Чтоб на айфончиге компилятор был, устраивающий лояров надкусанной компании, чтоб они не раздражали нерв своих гендиров, чтоб те могли смотреть на дедушку Столмана свысока?? Не, ну, бсдешников(*), понятно, хлебом не корми, дай Передовую Технологию(tm)(R) очередного ат-и-т. История, корни, уважуха.
> К слову, пока устанавливал обратно собранные GCC пакеты - всё решилось ещё
> в процессе.Захватывающе! Спасибо за интересный рассказ. Обязвтельно пишите ещё. Одного iZEN-я нам по-любому мало, чтоб держать на пульсе стучащего в сердце BSD(*).
Таков мой ""опыт "как есть", а кто-то просто увидел то, что хотел увидеть.""
// (*)Да, слово "Gentoo" я видел -- но этот линуксоид кряякает как бсдешник и т.д. "Премиссивщик" не так в ходу и не так обидно, я считаю.
..."Ждём FreeBSD 10+" Team. Основатель. [11ая не считается, не дождался.] http://www.opennet.me/openforum/vsluhforumID3/109353.html#347
1. Я раньше видел этот ник - от него когда-то писали адекватные комменты, но это было давно.2. Мне кажется, попробовать Clang на моей системе ради интереса - это МОЁ личное дело. То, что я здесь отписал - это тоже моё личное дело.
3. Всё остальное - поток сознания, оскорбления и выдумки. Стоило один раз упомянуть, как я попробовал Clang на выходных и у кого-то прорвало все поддоны - потекло ото всюду.
--
Если Чикатило в клетчатой рубашке когда-то был запечатлён, значит ли это, что все люди в клетчатой рубашке - маньяки и педофилы?
Хотя я не надеюсь на адекватную реакцию, ведь в своём выдуманном мирке, где А. Митрофанов - д'Артаньян, а остальные - известно кто, жить удобнее, верно?
> 1. Я раньше видел этот ник
> Если Чикатило в клетчатой рубашке
>в своём выдуманном мирке
>А. Митрофанов - д'АртаньянНа будущее: меня анализировать -- услуга платная. Вы уже задолжали, пройдите в кассу.
>, а остальные - известно кто, жить
> удобнее, верно?
> На будущее: меня анализировать -- услуга платная.Смешная шутка. После перехода на личности Ваши любые аргументы уже выглядят несерьёзно - Вы показали своё лицо.
Продолжать диалог с неадекватным инфантилом желания нет. Удачи.
> Шланг позволяет пихать модули-блобы, которые будут
> компилировать непонятно что и непонятно как.Поэтому можно взять .s файл и посмотреть, не напихали ли туда лишнего.
Ну увидишь ты там колл в середину блоба ...
Без него - не работает, с ним - не нужно ... но выбор всегда есть :-)
> Ладно EULA,..Кстати, что в ней написано? Стоит соглашаться?
>> Ладно EULA,..
> Кстати, что в ней написано? Стоит соглашаться?Если коротко, то в ней написано, что продавец ничего никому не должен и не гарантирует, а ты, покупатель, имеешь 100500 обязанностей перед продавцом.
> Ладно EULA, но что в нем такого необычного в этом компиляторе, что
> они сами его развивают?"AMD уже поняло что все эти независимые аффторы компиляторов типа GCC жирно проплаченны Intel-ом,
потому на базе форка LLVM+CLang пилят свой оптимизирующий под AMD компилятор
(правда тоже подонковски - только под самые последние свои модели ЦПУ, но может и на ранних будет профит кто знает) - AOCC{AMD Optimizing C,C++ Compiler}"
Охохо, понеслась звезда по кочкам. Пошли закрытые вендорские компиляторы.
Всего лишь кривой и сильно запоздавший ответ на Intel C Compiler, закрытый и нифига не дешевый !
> Всего лишь кривой и сильно запоздавший ответ на Intel C Compiler, закрытый
> и нифига не дешевый !С мест рапортуют, что Intel C Compiler, слава богу, где-то делает код быстрее GCC, но где-то и медленнее. Есть же высокоуровневые оптимизации типа rvalue ref, которые ускоряют любой код.
Это мы не говорим о том, что GCC - это обычно новейшее стандартное решение, что уменьшает кол-во геморроя при работе с.
> Пошли закрытые вендорские компиляторы.Первый раз, что-ли. Как пошли, так и пройдут.
Кому нужен этот геморрой - использование закрытого компилятора, когда рядом практически точно такой же, но открытый. Далеки как-то процессоро-ваятели от народа - временами вообще не понимают, что их процессор нафиг не нужен никому без компиляторов с РАЗНЫХ языков, а не только с C99 и C++03.
> Кому нужен этот геморрой - использование закрытого компилятораСамому вендору, чтобы циферки тестов красивые получались.
> их процессор нафиг не нужен никому без компиляторов с РАЗНЫХ языковЗолотые слова!
Да, вас нафиг с вашими brainfuckами разными.
С89 и С++~92 достаточно для любых задач, доказанно времнем,
а всё прочее - отвлекающее излишество и чисто маркеинг разработчиков компиляторов.
Писали вроде, что это просто тестовый полигон, все изменения будут попадать в основную ветку. Походу не хотели наступить на теже грабли что и с DC в свое время. На форониксе уже тесты есть, llvm 5 > aocc практически во всем.
Так почему не форк CLang - велосипеды кругом одни велоипеды
> llvm 5 > aoccЧот значит больше?
видимо быстрее.
А можно пруфлинков для тех, у кого гугл забанили?
> ...только в бинарном виде и требует принятия EULA-соглашения./dev/null
Там ещё есть плагин для Фортрана, но он требует Gfortran 4.8.2. Дополнительно приложили тарбол с бинарниками для систем, где Gfortran 4.8.2 отсутствует.
Ну Фортран ещё нас переживёт. Чай не Форт...
Хотя... А кто-то использует не родные спец.компиляторы Фортрана?
А Форт живёт себе, так же как и Фортран, но только в своей нише.
И Форт и Фортран живы, но очень уж узкая специализация.
И если Фортран ещё много проживёт, то Форт... ну это как ассемблер Z80. Жив в нашей памяти, но не более.
Раз им так нужен компилятор, что чего Open64 забросили?
Как там с компиляцией Linpack и результатами?
Был у меня пламенный атлон, и радон был, все ждал когда дрова откроют, чтоб можно было из каробки систему поставить и радоваться, но вот прошло уже 15 лет. И я совсем не жалею, что перешел на интель с инвидией.
> все ждал когда дрова откроютКак же ты бедный, зимами мёрз все эти 15 лет?
Я обогреватель купил, юниксвейней оно, когда вычисления и теплоотдача сами по себе.
Radeon до 2013-го тоже неплохо так грел. Потому что энергосбережения не было. Хотя в связке с проприетарным драйверов - было, но ты же - за открытые.
> совсем не жалею, что перешел на ... с инвидией.А, ну у NVidia-то, конечно, с открытостью лучше. )
Недавно ведь сам Линус сказал в камеру "Love you, NVidia" и "палец вверх" показал.
Да плевали владельцы геймерских карт от AMD на открытость, когда почти всё, что делается на проприетарных движках на открытых драйверах на 30-50% и более процентов медленнее, чем на AMDGPU-PRO. На том же ворониксе всё это есть. А ксонотики и cs свои сами себе засуньте..
Ну что, дождался, когда Невидия драйвера открыла? ;)
А ей зачем? они флагман, под них игры делают, а амд вечно догоняет, конечно он и подешевле, но отродясь с нвидью проблем не было, а с амд были, и видяхами, когда они консоль нормально отрисовать не могли, и с процами, а вот давеча интеловский девайс погорел, так его по горантии поменяли без лишьних вопросов. За неделю вопрос был решен, - доставка дхл за счет интела, а вот амдешный проц я помнится вспотел искать в питере под свою не молодую мать, а в мухосранске, если тока на авито повезет.Конечно переубедить кого-то в чем-то не получится, но альтернатива апстриму в даном контексте не стоит заморочек, открытость дров единственная фишка, которая могла уровнять нвидь с радеоном в моих глазах, но а если не судьба, то лучше лучшее, чем вечный второй номер.
> А ей зачем? они флагман, под них игры делают, а амд вечно догоняет,Есть некоторые изменения.
https://www.notebookcheck-ru.com/Intel-vypustit-processor-s-...
> отродясь с нвидью проблем не былоНикогда система наглухо не зависала из-за блоба? Ну что, повезло тебе.
А что, у амд как-то иначе? а вообще нвидь никогда, а вот радеон бывало, систему не вешал, но приходилось по сети цепляться ребутать, так как на экране была какая-то абстракция.
> А ей зачем? они флагман, под них игры делают, а амд вечно догоняет, конечно он и подешевлеНу да, ну да, тото я смотрю их в эппле перестали сатвить.
> Ну да, ну да, тото я смотрю их в эппле перестали сатвить.Эпл показатель чего? с каких пор?
А я сам отвечу, показатель жадности, всегда, за доллар удавятся и нас рать, что вреда юзеру на пять, история есть показательная, когда маркетолог выдрал какую-то запчасть и сказал продавать так, толи куллер был шумный, толи уже не помню, но партию потом отозывали, когда они гореть начали.
Недавно задавал вопрос на форуме. Не на эту тему. И среди прочих вещей, узнал немного о векторизации в компиляторе GCC:> Под neon, компилер часто генерит не слишком хороший код, и наибольший прирост утдаётся получить, написав на ассемблере. Но это сильно зависит от задачи. Но однозначно даже при просто компиляции, при включённой векторизации, если завекторизовалось нормально - будет быстрее. К сожалению с векторизацией в последних компиляторах как-то не очень, во времена gcc-3.x было повеселее. Ещё надо учитывать что многие инструкции neon требуют строгого выравнивания, и новый gcc (>= 4.x) если не может выровнять, кладёт болт. Если оптимизация важна, нужно вручную постараться через __attribute__. Там достаточно много тонкостей.
> Типичный случай - если gcc не знает заранее, что аргументы функции выровнены, он не будет векторизовать код с этими аргументами, их нужно специально маркировать, и иногда сплясать с бубном. Раньше это всё само делалось компилятором, но видать пришел кто-то умный и сказал, что так низзя и надо заставить народ работать.
>> If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=‘neon’), note that floating-point operations are not generated by GCC’s auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision.
> Векторизация перпендикулярна floating point, но да, и это тоже. Когда я этим активно занимался всё было гораздо проще - включаешь neon и векторизацию и получаешь ускорение в 5 раз на 1-ядерном Cortex-A8. Сейчас уже всё не так. Консерваторы, блин.
"Векторизация перпендикулярна floating point" - спецы, б**ь
> "Векторизация перпендикулярна floating point" - спецы, б**ьА что - нет?
>> "Векторизация перпендикулярна floating point" - спецы, б**ь
> А что - нет?Вообще-то, FP-вычисления, особенно в циклах, векторизуются в первую очередь и наиболее эффективно. А вот с целочисленными вычислениями с их изменяющейся шириной и обилием экзотических операций типа сдвига на runtime-величину зачастую возникают проблемы и эффективность падает.
> Вообще-то, FP-вычисления, особенно в циклах, векторизуются в первую очередь и наиболее
> эффективно. А вот с целочисленными вычислениями с их изменяющейся шириной и
> обилием экзотических операций типа сдвига на runtime-величину зачастую возникают проблемы
> и эффективность падает.Ну да, не совсем перпендикулярна.
> К сожалению с векторизацией в последних компиляторах как-то не очень, во времена gcc-3.x было повеселее.Векторизация появилась только в 4.x. Первая версия в 4.0, но более-менее юзабельная заметно позже, где-то после 4.2.
1. Зачем отдельный компилятор?
2. Если эта фигня для тестирования, кто-нибудь планирует в итоге перенести это всё в LLVM и GCC?
Слили open64, гады
А почему нельзя свои улучшения отправить в проект llvm и не создавать форков?
Очень много вложено в Zen. Пиар по всем фронтам!
Правильно сделали, у zen все-таки продвинутая архитектура.
Даже если их архитектуру называть продвинутой, что с этого? Почему "продвинутость" стала препятствием к унификации?
А тестировать на ком и с кем?
respect!