Проект LinuxDNA (http://www.linuxdna.com/), осуществляющий адаптацию Linux ядра для сборки компилятором icc (Intel C/C++ Compiler), достиг (http://www.linuxjournal.com/content/linuxdna-supercharges-li...) первых успехов - модифицированное ядро 2.6.22 не только было успешно собрано при помощи icc 9, но и показало работоспособность в качестве замены стандартного ядра в Gentoo Linux. В планах: обеспечение поддержки icc-совместимой ветки синхронно с основной ветки ядра, переход на использование icc версий 10.1 и 11.
Сборка компилятором icc позволит оптимизировать производительность ядра, причем значительно. Сборка ядра в icc позволяет обеспечить прирост производительности некоторых подсистем ядра до 40%, что актуально в системах требующих интенсивных вычислений - от кластеров для научных расчетов до игровых машин. В среднем, производительность всего ядра, после сборки в icc, увеличивается на 8-9%.
Главными причинами генерации более быстрого года в icc называются...URL: http://www.linuxjournal.com/content/linuxdna-supercharges-li...
Новость: https://www.opennet.ru/opennews/art.shtml?num=20507
Еще бы сравнительные тесты этого счастья увидеть, а не абстрактное "прирост производительности некоторых подсистем"...
> что актуально в системах требующих интенсивных вычислений - от кластеров
> для научных расчетовЯдро не умеет производить научных рассчетов...
> до игровых машин.
И игры сами себе все данные считают :D
В итоге прироста в общем случае будет не 40% а "с гулькин нос", 40% реально увидеть только там где все в ядро упирается а это какие-то весьма экзотичные случаи.
Кстати этот icc вроде проприетарщина? :(
icc свободен для некоммерческого использования. Можно скачать с сайта Intel.
Он не свободен, а свободно распространяется для некоммерческого использования. А значит глубоко проприетарен и ненужен!
кроме того там охереешь его качать. сто шагов, регистрация, авторизация, лицензии -- даже почище микрософтовских ресурсов. я года 2 назад хотел попробовать -- на 6-м шаге плюнул и ушел. реально весь этот проприетарный бред достает.
Не знаю, как два года назад, а сейчас два шага:
1. подтверждение лицензии.
2. указание мыла(куда присылается серийник).Ценность icc не столько в компиляторе, сколько в паре библиотечек, которые с ним идут. Они стоят ввода двух строк текста и трех кликов мышки.
>Они стоят ввода двух строк текста и трех кликов мышки.Они поди тоже "бесплатны только для некоммерческого использования"?Тогда их ценность стремится к нулю - музейный артефакт на подрочить.Потому что весь мозг сломаешь - является ли такое или этакое использование некоммерческим или нет.Ну его нафиг на проприетарь подсаживаться.Знаю я это - первая доза бесплатно называется.С MS такого уже наелся, больше неохота.
> icc свободен для некоммерческого использования.Т.е. он БЕСПЛАТЕН для некоммерческого использования.
> Можно скачать с сайта Intel.
Покорно благодарю, на таких условиях пусть сами и качают, имхо. Я не собираюсь гарантировать интелю что буду всю жизнь компилить только бесплатно и не получу за это ни цента а 8-9% выигрыша в ядре скорее всего я просто не замечу ни в каких реальных применениях (только на синтетических бенчах самого ядра).И кстати припоминается какое-то бурчание по части работы такого кода на АМД.
ИМХО так лучше б кому нужна скорость оптимизили GCC чем на всякую проприетарь закладываться.
> И кстати припоминается какое-то бурчание по части работы такого кода на АМД.Они туда тормозилки засовывали, для icc есть правильный патчик ;-)
>Они туда тормозилки засовывали, для icc есть правильный патчик ;-)Хм, как-то в облом мне с таким вендором дело иметь который гадит втихарика.Не люблю западлостроителей.Лучше я как-нить gcc'ом обойдусь.Там западлостроения не приходится ожидать.Ни для интель, ни для амд, ни для арм, ни для мипс, ни для авр... как минимум, специального.
>Они туда тормозилки засовывали, для icc есть правильный патчик ;-)Ссылка?
Они просто использовали специфические и недокументированные свойства собственных процессоров. На AMD код работает медленнее просто потому, что эти свойства там другие.
>Т.е. он БЕСПЛАТЕН для некоммерческого использования.Да, так правильнее
>Покорно благодарю, на таких условиях пусть сами и качают, имхо. Я не
>собираюсь гарантировать интелю что буду всю жизнь компилить только бесплатно и
>не получу за это ни цента а 8-9% выигрыша в ядре
>скорее всего я просто не замечу ни в каких реальных применениях
>(только на синтетических бенчах самого ядра).И кстати припоминается какое-то бурчание по
>части работы такого кода на АМД.
>
>ИМХО так лучше б кому нужна скорость оптимизили GCC чем на всякую
>проприетарь закладываться.Я не скажу за ядро, но у меня на математических задачах icc даёт прирост производительности раза в полтора по сравнению с gcc. Это на AMD64 (правда, на 32-битной архитектуре прироста по сравнению с gcc-3.3.6 практически нет). Как закладывается оптимизация в gcc, я тоже видел. На тех же задачах gcc-4 отстаёт от gcc-3.3.6 процентов на 20.
>> что актуально в системах требующих интенсивных вычислений - от кластеров для научных расчетов
> Ядро не умеет производить научных рассчетов...Сказано же "от КЛАСТЕРОВ для научных расчетов". "Кластер" - это в т.ч. программное обеспечение по обмену данными между узлами кластера; если обмен интенсивный, то затраты вычислительной мощности на обмен данными будет существенным и нуждается в оптимизации.
1. если программа криво написана, то и оптимизация ядра нужна позарез.
2. любая конечная оптимизация требует оптимизации под платформу. см пункт 1.
Сферический прирост в вакууме от icc достигается за счет использования PGO и IPO. Один реализован в gcc 4.0, другой в gcc 4.1.
И где подвох?
> за счет использования PGO и IPO.
> Один реализован в gcc 4.0, другой в gcc 4.1.И PGO и IPO это в первую очередь инфраструктура.
Тот факт, что в оптимизаторе появилась возможность узнать профиль графа потока управления
и делать межпроцедурные оптимизации это хорошо. Теперь несколько лет это
все будет обрастать мясом, старые оптимизации будут учиться этой информацией пользоваться,
будут писаться новые оптимизации с прицелом на доступность этих средств.
а LLVM не умеет все это делать? сомневаюсь
>а LLVM не умеет все это делать? сомневаюсьЕсть же тесты LLVM. Пока что она не быстрее гцц, за исключением редких случаев.
В какой-то момент интеловский компилятор стал требовать наличия совершенно определённого gcc (ну, и способ поиска этого gcc был, мягко говоря, не универсальным). Эта технология всё ещё в деле?
>В какой-то момент интеловский компилятор стал требовать наличия совершенно определённого gcc (ну,
>и способ поиска этого gcc был, мягко говоря, не универсальным). Эта
>технология всё ещё в деле?If you are using the TR1 (C++ Library Technical Report 1) system headers on a system with
g++ version 4.3 or later installed, the Intel C/C++ compiler will give errors when it tries to compile the <type_traits> header file. This is because the Intel C/C++ compiler does not yet support the C++0x feature called variadic templates. You will see these types of compilationerrors:
../include/c++/4.3.0/tr1_impl/type_traits(170): error: expected an
identifier
template<typename _Res, typename... _ArgTypes>
include/c++/4.3.0/tr1_impl/type_traits(171): error: expected a ")"
struct __is_function_helper<_Res(_ArgTypes...)>There is no workaround, other than not using these headers or using an older version of the g++ compiler.
Ребята за зря потратили время. Практическая ценность такого ядра мягко говоря сомнительная. Лучше бы занялись развитием PGO и IPO в GCC.
Ядро можно собирать с опцией не выше -O2, лучше бы разработчики ядра писали нормально код, чтобы любой компилятор мог его легко компилить и оптимизировать на этапе компиляции.
Нормально это как? Следовать стандартам? так следуют, если где-то не следуют то патчи исправляющие это легко пропихнуть. А вот писать код так, чтобы держать в уме те извращения, которые делают с кодом компилятор, хм. Вообще-то это работа компилятора, сделать так, чтобы любой код, соответствующий стандарту работал. Также как работа производиелей браузеров, чтобы любой код, соответствующий стандарту - работал. Я думаю вас напряжёт, если вы воткнёте клавиатуру в usb, полностью соответствующую стандартам и обнаружите, что система её не воспринимает. Вот тут такая же байда.
Если компилятор явно не говорит о ошибках в коде, но при этом ломает код - значит у производителя компилятора надо вырвать руки, по саму жопу.
>Следовать стандартам? так следуют
>А вот писать код так, чтобы держать в уме те извращения, которые делают с кодом компилятор, хм. Вообще-то это работа компилятора, сделать так, чтобы любой код, соответствующий стандарту работал.Так кто же нарушает стандарт, и ломает работу?
А никто. Потому что там где возникают проблемы никаких стандартов нет!
И поведение Линуса, то кричащего что volatile ненужная ерунда, то в друг обвиняющего gcc, что он оптимизаруя начинает спекулятивно загружать переменную в регистр до выяснения необходимости её загрузки и ломая блокировки в linux, говорит о том что врядли gcc виновен.
Нафига тогда ядро под gcc компилить? Если gcc фуфло, то какой компайлер использовать?
>Нафига тогда ядро под gcc компилить? Если gcc фуфло, то какой компайлер
>использовать?Свой напишите, лучше, фигле.Слабо?Или вы предлагаете компилить открытую операционку закрытыми компилерами?А оно, простите, нато?Ну если вам нато - вы и пашете, как вон те чудаки с интель компилером.Вот только майнстримом оно не станет и поделом.Как максимум будет юзаться теми кому просто позарез надо а по другому - ну совсем никак.Это тупиковый путь эволюции, ИМХО.
Почему тогда разработчики кода ядра используют фичи gcc?
ты типа VisualStudio предлагаешь поддерживать ? :D
Когда-то я программил сертифицированную криптобиблиотеку, которая теперь работает в некоторых системах банк клиент. Так вот обычный ГОСТ 28147-89 написанный на С в котором одна математика (XOR, +, <<, >>) скомпиленный на INTEL C COMPILER, без изменения кода давал прирост действительно порядка 40% в сравнении с другими. Потом точно также перекомпил модули ЭЦП с математикой на эллиптических кривых, точно такой же получив значительный прирост.
Так что это не байки, попробуйте просто скомпилить код без его изменения и Intel вас приятно удивит.
а некоторые - это какие? и только ли в банк-клиентах? может и в СБИсах разных и такснетреферантах? Вот из-за кого эти вещи не не работают в wine :)
>Главными причинами генерации более быстрого года в icc называются...Почему в OpenBSD хотят заменить GCC на другой компилятор, сделанный по науке:
http://habrahabr.ru/blogs/os/31277/
>Почему в OpenBSD хотят заменить GCC на другой компилятор, сделанный по наукеКак там принято, по тараканам в башке -- "лицензия некошерная".
Они бы лучше биглоки из ядра убрали и порты в порядок привели.
ну и почему ещё не заменили?
> Когда-то я программил сертифицированную криптобиблиотеку, которая теперь работает в некоторых системах банк клиент. Так вот обычный ГОСТ 28147-89 написанный на С в котором одна математика (XOR, +, <<, >>) скомпиленный на INTEL C COMPILER, без изменения кода давал прирост действительно порядка 40% в сравнении с другими. Потом точно также перекомпил модули ЭЦП с математикой на эллиптических кривых, точно такой же получив значительный прирост.Так что это не байки, попробуйте просто скомпилить код без его изменения и Intel вас приятно удивит.
ну и причем здесь ядро? математики там минимум.
а как с производительностью у программ, компиленных c icc и запущенных на AMD проце? я слышал все оптимизации Intel компилятора тут сходят практически на нет. Или же все нормально?
>а как с производительностью у программ, компиленных c icc и запущенных на
>AMD проце? я слышал все оптимизации Intel компилятора тут сходят практически
>на нет. Или же все нормально?Для i386 или x86_64?
Для первого - скорее всего Вы правы. Для последнего, думается, разница будет незначительной.
Ждем, когда соберут с помощью Microsoft Visual Studio.
>Ждем, когда соберут с помощью Microsoft Visual Studio.и сделают ядром windows? =)
Учитывая то, что победит не виндовс, то скорее не ядром виндовс, а будет нечто вроде IBM Winux 8 on top GNU/LINUX and wine
ну вот теперь ещё одна программа нормально работает в линукс -радоваться надо.Весь софт делиться на две категории -те которые уже работают в линукс и те которые будут работать.
>ну вот теперь ещё одна программа нормально работает в линукс -радоваться надо.Весь
>софт делиться на две категории -те которые уже работают в линукс
>и те которые будут работать.icc как работал, так примерно и работает... эт как раз не новость :)
Как народ бодренько обосрал один из лучших (если не лучший) компилятор в мире... Господа - снобизм хорош когда вы для домашнего использования что-то собираете, а когда вам нужно бороться за рынок, его нужно засовывать в дальние тёплые места.
Есть люди которые не понимают, что не все хотят быть обслуживающим персоналом (пусть и в информационной области), есть люди которые хотят делать готовый продукт (программу) и продавать его. Это всегда было, есть и будет и ничего в будущем (в значительной степени) не изменится
watcom-ом бы собрали. было бы забавно посмотреть :)// wbr
Возможно кто то знает С++ лучше чем ребята из Intel, это сложный вопрос. Но вот лучше intel оптимизировать компилятор своей разработки под свои же процессоры едва ли кто нибудь сможет.Разве что amd? ;-)
>Возможно кто то знает С++ лучше чем ребята из Intel, это сложный
>вопрос. Но вот лучше intel оптимизировать компилятор своей разработки под свои
>же процессоры едва ли кто нибудь сможет.
>
>Разве что amd? ;-)жаль что у amd нет своего компилятора...
или есть, а я просто не знаю?..
>> жаль что у amd нет своего компилятора... или есть, а я просто не знаю?..хм судя по тому как они открывают спецификации на свои чипы они сделали ставку на открытые технологии. значит всетаки родным компилятором амд будет gcc