The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Linux ядро адаптировано для сборки компилятором Intel C/C++

27.02.2009 23:48

Проект LinuxDNA, осуществляющий адаптацию Linux ядра для сборки компилятором icc (Intel C/C++ Compiler), достиг первых успехов - модифицированное ядро 2.6.22 не только было успешно собрано при помощи icc 9, но и показало работоспособность в качестве замены стандартного ядра в Gentoo Linux. В планах: обеспечение поддержки icc-совместимой ветки синхронно с основной ветки ядра, переход на использование icc версий 10.1 и 11.

Сборка компилятором icc позволит оптимизировать производительность ядра, причем значительно. Сборка ядра в icc позволяет обеспечить прирост производительности некоторых подсистем ядра до 40%, что актуально в системах требующих интенсивных вычислений - от кластеров для научных расчетов до игровых машин. В среднем, производительность всего ядра, после сборки в icc, увеличивается на 8-9%.

Главными причинами генерации более быстрого кода в icc называются два ключевых метода оптимизации: IPO (Inter Procedural Optimization) и PGO (Profile Guided Optimization). В IPO используется коллекция эвристических методов оптимизации в контексте работы набора связанных функций, оценивая работу программы в целом, а не отдельных блоков кода. В PGO задействованы средства многоэтапной сборки - на первой стадии формируется эталонный код с метками, который подвергается анализу во время тестового запуска, посте чего производится рекомпиляция с учетом особенностей использования. Поддержка PGO оптимизации реализована в GCC 4.0, IPO - в GCC 4.1.

  1. Главная ссылка к новости (http://www.linuxjournal.com/co...)
  2. OpenNews: Выпущен релиз Linux версии компилятора Intel C++ Compiler 11.0
  3. OpenNews: Сравнение производительности Си/Си++ компиляторов под Linux
  4. OpenNews: Эффективность опций оптимизации в icc и gcc. Причины утечек памяти.
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/20507-optimization
Ключевые слова: optimization, linux, kernel, compile, gcc, icc
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (47) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, remes (ok), 01:26, 28/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Еще бы сравнительные тесты этого счастья увидеть, а не абстрактное "прирост производительности некоторых подсистем"...
     
  • 1.2, User294 (ok), 01:53, 28/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > что актуально в системах требующих интенсивных вычислений - от кластеров
    > для научных расчетов

    Ядро не умеет производить научных рассчетов...

    > до игровых машин.

    И игры сами себе все данные считают :D

    В итоге прироста в общем случае будет не 40% а "с гулькин нос", 40% реально увидеть только там где все в ядро упирается а это какие-то весьма экзотичные случаи.

    Кстати этот icc вроде проприетарщина? :(

     
     
  • 2.6, Michael (??), 04:33, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    icc свободен для некоммерческого использования. Можно скачать с сайта Intel.

     
     
  • 3.8, ixrws (?), 08:51, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Он не свободен, а свободно распространяется для некоммерческого использования. А значит глубоко проприетарен и ненужен!
     
     
  • 4.18, fresco (??), 13:44, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    кроме того там охереешь его качать. сто шагов, регистрация, авторизация, лицензии -- даже почище микрософтовских ресурсов. я года 2 назад хотел попробовать -- на 6-м шаге плюнул и ушел. реально весь этот проприетарный бред достает.
     
     
  • 5.21, 4ertus2 (?), 14:46, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю, как два года назад, а сейчас два шага:
    1. подтверждение лицензии.
    2. указание мыла(куда присылается серийник).

    Ценность icc не столько в компиляторе, сколько в паре библиотечек, которые с ним идут. Они стоят ввода двух строк текста и трех кликов мышки.

     
     
  • 6.28, User294 (ok), 15:49, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Они стоят ввода двух строк текста и трех кликов мышки.

    Они поди тоже "бесплатны только для некоммерческого использования"?Тогда их ценность стремится к нулю - музейный артефакт на подрочить.Потому что весь мозг сломаешь - является ли такое или этакое использование некоммерческим или нет.Ну его нафиг на проприетарь подсаживаться.Знаю я это - первая доза бесплатно называется.С MS такого уже наелся, больше неохота.

     
  • 3.27, User294 (ok), 15:38, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >  icc свободен для некоммерческого использования.

    Т.е. он БЕСПЛАТЕН для некоммерческого использования.

    > Можно скачать с сайта Intel.

    Покорно благодарю, на таких условиях пусть сами и качают, имхо. Я не собираюсь гарантировать интелю что буду всю жизнь компилить только бесплатно и не получу за это ни цента а 8-9% выигрыша в ядре скорее всего я просто не замечу ни в каких реальных применениях (только на синтетических бенчах самого ядра).И кстати припоминается какое-то бурчание по части работы такого кода на АМД.

    ИМХО так лучше б кому нужна скорость оптимизили GCC чем на всякую проприетарь закладываться.

     
     
  • 4.29, Michael Shigorin (ok), 15:53, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > И кстати припоминается какое-то бурчание по части работы такого кода на АМД.

    Они туда тормозилки засовывали, для icc есть правильный патчик ;-)

     
     
  • 5.44, User294 (ok), 22:53, 01/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Они туда тормозилки засовывали, для icc есть правильный патчик ;-)

    Хм, как-то в облом мне с таким вендором дело иметь который гадит втихарика.Не люблю западлостроителей.Лучше я как-нить gcc'ом обойдусь.Там западлостроения не приходится ожидать.Ни для интель, ни для амд, ни для арм, ни для мипс, ни для авр... как минимум, специального.

     
  • 5.49, ximaera (?), 21:01, 10/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Они туда тормозилки засовывали, для icc есть правильный патчик ;-)

    Ссылка?

    Они просто использовали специфические и недокументированные свойства собственных процессоров. На AMD код работает медленнее просто потому, что эти свойства там другие.

     
  • 4.38, Michael (??), 01:51, 01/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Т.е. он БЕСПЛАТЕН для некоммерческого использования.

    Да, так правильнее

    >Покорно благодарю, на таких условиях пусть сами и качают, имхо. Я не
    >собираюсь гарантировать интелю что буду всю жизнь компилить только бесплатно и
    >не получу за это ни цента а 8-9% выигрыша в ядре
    >скорее всего я просто не замечу ни в каких реальных применениях
    >(только на синтетических бенчах самого ядра).И кстати припоминается какое-то бурчание по
    >части работы такого кода на АМД.
    >
    >ИМХО так лучше б кому нужна скорость оптимизили GCC чем на всякую
    >проприетарь закладываться.

    Я не скажу за ядро, но у меня на математических задачах icc даёт прирост производительности раза в полтора по сравнению с gcc. Это на AMD64 (правда, на 32-битной архитектуре прироста по сравнению с gcc-3.3.6 практически нет). Как закладывается оптимизация в gcc, я тоже видел. На тех же задачах gcc-4 отстаёт от gcc-3.3.6 процентов на 20.

     
  • 2.17, Дмитрий Ю. Карпов (?), 13:41, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >> что актуально в системах требующих интенсивных вычислений - от кластеров для научных расчетов
    > Ядро не умеет производить научных рассчетов...

    Сказано же "от КЛАСТЕРОВ для научных расчетов". "Кластер" - это в т.ч. программное обеспечение по обмену данными между узлами кластера; если обмен интенсивный, то затраты вычислительной мощности на обмен данными будет существенным и нуждается в оптимизации.

     
  • 2.43, Karbofos (??), 22:44, 01/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    1. если программа криво написана, то и оптимизация ядра нужна позарез.
    2. любая конечная оптимизация требует оптимизации под платформу. см пункт 1.
     

  • 1.3, 1 (??), 02:46, 28/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сферический прирост в вакууме от icc достигается за счет использования PGO и IPO. Один реализован в gcc 4.0, другой в gcc 4.1.
    И где подвох?
     
     
  • 2.4, horsh (??), 02:58, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > за счет использования PGO и IPO.
    > Один реализован в gcc 4.0, другой в gcc 4.1.

    И PGO и IPO это в первую очередь инфраструктура.
    Тот факт, что в оптимизаторе появилась возможность узнать профиль графа потока управления
    и делать межпроцедурные оптимизации это хорошо. Теперь несколько лет это
    все будет обрастать мясом, старые оптимизации будут учиться этой информацией пользоваться,
    будут писаться новые оптимизации с прицелом на доступность этих средств.

     

  • 1.5, Аноним (5), 04:07, 28/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а LLVM не умеет все это делать? сомневаюсь
     
     
  • 2.10, Аноним (5), 09:55, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >а LLVM не умеет все это делать? сомневаюсь

    Есть же тесты LLVM. Пока что она не быстрее гцц, за исключением редких случаев.

     

  • 1.7, anonymous (??), 08:16, 28/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В какой-то момент интеловский компилятор стал требовать наличия совершенно определённого gcc (ну, и способ поиска этого gcc был, мягко говоря, не универсальным). Эта технология всё ещё в деле?
     
     
  • 2.22, 4ertus2 (?), 14:54, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >В какой-то момент интеловский компилятор стал требовать наличия совершенно определённого 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 compilation

    errors:
    ../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.

     

  • 1.11, Юрий (??), 10:45, 28/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ребята за зря потратили время. Практическая ценность такого ядра мягко говоря сомнительная. Лучше бы занялись развитием PGO и IPO в GCC.
     
     
  • 2.14, yantux (??), 12:46, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Ядро можно собирать с опцией не выше -O2, лучше бы разработчики ядра писали нормально код, чтобы любой компилятор мог его легко компилить и оптимизировать на этапе компиляции.
     
     
  • 3.15, ixrws (?), 13:13, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Нормально это как? Следовать стандартам? так следуют, если где-то не следуют то патчи исправляющие это легко пропихнуть. А вот писать код так, чтобы держать в уме те извращения, которые делают с кодом компилятор, хм. Вообще-то это работа компилятора, сделать так, чтобы любой код, соответствующий стандарту работал. Также как работа производиелей браузеров, чтобы любой код, соответствующий стандарту - работал. Я думаю вас напряжёт, если вы воткнёте клавиатуру в usb, полностью соответствующую стандартам и обнаружите, что система её не воспринимает. Вот тут такая же байда.
    Если компилятор явно не говорит о ошибках в коде, но при этом ломает код - значит у производителя компилятора надо вырвать руки, по саму жопу.
     
     
  • 4.37, Аноним (5), 23:45, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Следовать стандартам? так следуют
    >А вот писать код так, чтобы держать в уме те извращения, которые делают с кодом компилятор, хм. Вообще-то это работа компилятора, сделать так, чтобы любой код, соответствующий стандарту работал.

    Так кто же нарушает стандарт, и ломает работу?

    А никто. Потому что там где возникают проблемы никаких стандартов нет!

    И поведение Линуса, то кричащего что volatile ненужная ерунда, то в друг обвиняющего gcc, что он оптимизаруя начинает спекулятивно загружать переменную в регистр до выяснения необходимости её загрузки и ломая блокировки в linux, говорит о том что врядли gcc виновен.

     
  • 4.40, yantux (??), 17:47, 01/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Нафига тогда ядро под gcc компилить? Если gcc фуфло, то какой компайлер использовать?
     
     
  • 5.47, User294 (??), 20:48, 02/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Нафига тогда ядро под gcc компилить? Если gcc фуфло, то какой компайлер
    >использовать?

    Свой напишите, лучше, фигле.Слабо?Или вы предлагаете компилить открытую операционку закрытыми компилерами?А оно, простите, нато?Ну если вам нато - вы и пашете, как вон те чудаки с интель компилером.Вот только майнстримом оно не станет и поделом.Как максимум будет юзаться теми кому просто позарез надо а по другому - ну совсем никак.Это тупиковый путь эволюции, ИМХО.

     
  • 4.41, yantux (??), 17:50, 01/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Почему тогда разработчики кода ядра используют фичи gcc?
     
  • 3.34, sluge (??), 20:10, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    ты типа VisualStudio предлагаешь поддерживать ? :D
     

  • 1.12, Аноним (12), 11:45, 28/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Когда-то я программил сертифицированную криптобиблиотеку, которая теперь работает в некоторых системах банк клиент. Так вот обычный ГОСТ 28147-89 написанный на С в котором одна математика (XOR, +, <<, >>) скомпиленный на INTEL C COMPILER,  без изменения кода давал прирост действительно порядка 40% в сравнении с другими. Потом точно также перекомпил модули ЭЦП с математикой на эллиптических кривых, точно такой же получив значительный прирост.
    Так что это не байки, попробуйте просто скомпилить код без его изменения и Intel вас приятно удивит.
     
  • 1.13, Аноним (12), 12:17, 28/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а некоторые - это какие? и только ли в банк-клиентах? может и в СБИсах разных и такснетреферантах? Вот из-за кого эти вещи не не работают в wine :)
     
  • 1.16, iZEN (ok), 13:31, 28/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Главными причинами генерации более быстрого года в icc называются...

    Почему в OpenBSD хотят заменить GCC на другой компилятор, сделанный по науке:
    http://habrahabr.ru/blogs/os/31277/


     
     
  • 2.31, Michael Shigorin (ok), 17:21, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Почему в OpenBSD хотят заменить GCC на другой компилятор, сделанный по науке

    Как там принято, по тараканам в башке -- "лицензия некошерная".

     
  • 2.36, q (??), 23:39, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Они бы лучше биглоки из ядра убрали и порты в порядок привели.
     
  • 2.39, vitek (??), 12:06, 01/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    ну и почему ещё не заменили?
     

  • 1.19, Аноним (5), 14:19, 28/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Когда-то я программил сертифицированную криптобиблиотеку, которая теперь работает в некоторых системах банк клиент. Так вот обычный ГОСТ 28147-89 написанный на С в котором одна математика (XOR, +, <<, >>) скомпиленный на INTEL C COMPILER,  без изменения кода давал прирост действительно порядка 40% в сравнении с другими. Потом точно также перекомпил модули ЭЦП с математикой на эллиптических кривых, точно такой же получив значительный прирост.

    Так что это не байки, попробуйте просто скомпилить код без его изменения и Intel вас приятно удивит.

    ну и причем здесь ядро? математики там минимум.
    а как с производительностью у программ, компиленных c icc и запущенных на AMD проце? я слышал все оптимизации Intel компилятора тут сходят практически на нет. Или же все нормально?

     
     
  • 2.23, 4ertus2 (?), 15:07, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >а как с производительностью у программ, компиленных c icc и запущенных на
    >AMD проце? я слышал все оптимизации Intel компилятора тут сходят практически
    >на нет. Или же все нормально?

    Для i386 или x86_64?
    Для первого - скорее всего Вы правы. Для последнего, думается, разница будет незначительной.

     

  • 1.20, Аноним (5), 14:33, 28/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ждем, когда соберут с помощью Microsoft Visual Studio.
     
     
  • 2.24, Некто (??), 15:12, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Ждем, когда соберут с помощью Microsoft Visual Studio.

    и сделают ядром windows? =)

     
     
  • 3.25, ixrws (?), 15:20, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Учитывая то, что победит не виндовс, то скорее не ядром виндовс, а будет нечто вроде IBM Winux 8 on top GNU/LINUX and wine
     

  • 1.30, DmA (??), 16:21, 28/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ну вот теперь ещё одна программа нормально работает в линукс -радоваться надо.Весь софт делиться на две категории -те которые уже работают в линукс и те которые будут работать.
     
     
  • 2.32, Michael Shigorin (ok), 17:24, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >ну вот теперь ещё одна программа нормально работает в линукс -радоваться надо.Весь
    >софт делиться на две категории -те которые уже работают в линукс
    >и те которые будут работать.

    icc как работал, так примерно и работает... эт как раз не новость :)

     

  • 1.33, Konwin (??), 18:37, 28/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как народ бодренько обосрал один из лучших (если не лучший) компилятор в мире... Господа - снобизм хорош когда вы для домашнего использования что-то собираете, а когда вам нужно бороться за рынок, его нужно засовывать в дальние тёплые места.
     
     
  • 2.35, Ariel (??), 20:41, 28/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Есть люди которые не понимают, что не все хотят быть обслуживающим персоналом (пусть и в информационной области), есть люди которые хотят делать готовый продукт (программу) и продавать его. Это всегда было, есть и будет и ничего в будущем (в значительной степени) не изменится

     

  • 1.42, klalafuda (?), 18:38, 01/03/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/

    watcom-ом бы собрали. было бы забавно посмотреть :)

    // wbr

     
  • 1.45, Аноним (12), 01:35, 02/03/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Возможно кто то знает С++ лучше чем ребята из Intel, это сложный вопрос. Но вот лучше intel оптимизировать компилятор своей разработки под свои же процессоры едва ли кто нибудь сможет.

    Разве что amd? ;-)

     
     
  • 2.46, unknown (??), 14:03, 02/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Возможно кто то знает С++ лучше чем ребята из Intel, это сложный
    >вопрос. Но вот лучше intel оптимизировать компилятор своей разработки под свои
    >же процессоры едва ли кто нибудь сможет.
    >
    >Разве что amd? ;-)

    жаль что у amd нет своего компилятора...
    или есть, а я просто не знаю?..

     
     
  • 3.48, fooser (?), 01:40, 03/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >> жаль что у amd нет своего компилятора... или есть, а я просто не знаю?..

    хм судя по тому как они открывают спецификации на свои чипы они сделали ставку на открытые технологии. значит всетаки родным компилятором амд будет gcc

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру