LINUX.ORG.RU
ФорумTalks

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


0

0

[копипаста с OpenNews]

Проект 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.


http://www.linuxjournal.com/content/linuxdna-supercharges-linux-intel-cc-comp...
http://www.linuxdna.com/

★★★★★

> В среднем, производительность всего ядра, после сборки в icc, увеличивается на 8-9%.

По сравнению с ядром, собранным какой версией GCC?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Earlier work at compiling the Linux kernel with ICC found that ICC provided up to a 40% boost in performance. Ingo A. Kubblin, a German developer that worked on the original ICC porting project in 2004, gave the following quote: "... boost up to 40% for certain kernel parts and an average boost of 8-9% possible"

Если судить из фактов в этом тескте, то данные за 2004-й год, т.е. уже устаревшие со стороны обоих компиляторов. Из раздела - бабки на базаре обсуждают.

Spectr ★★★
()
Ответ на: комментарий от Spectr

> Если судить из фактов в этом тескте, то данные за 2004-й год

Не совсем так, там мутная формулировка - слова про 8% сказаны парнем, который учавствовал в проекте 2004 года, а к какому времени они относятся - ХЗ. Но отсуствие baseline-версии GCC как бэ намекает. Когда там 2.6.22 вышел?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

"... boost up to 40% for certain kernel parts and an average boost of 8-9% possible"

This early work was based on version 8 of ICC; current efforts are using versions 10.1 and 11.

- т.е. старым компилятором версии 8, а сейчас у них версию 10 используют. Настораживает, что у них жуткие пляски с бубном по версиям компиляторов - с GCC там просто ветка обычно поддерживается без особых проблем, а тут уже с точностью до третьего числа в номере версии ICC требуют...

Spectr ★★★
()

icc не подходит.

Всё равно я буду собирать gcc, потому что он кошерен и распространён.

Camel ★★★★★
()

Боян, кода 3 на зад уже собирал.

madcore ★★★★★
()
Ответ на: комментарий от Spectr

>- т.е. старым компилятором версии 8, а сейчас у них версию 10 используют. Настораживает, что у них жуткие пляски с бубном по версиям компиляторов - с GCC там просто ветка обычно поддерживается без особых проблем, а тут уже с точностью до третьего числа в номере версии ICC требуют...

На самом деле любой версией gcc любое ведро тоже не соберешь просто так...

Когда последний раз видел подобную затею, там собиралось враппером, который вперемешку использовал gcc и icc, ибо icc сегфолтится на типичном ровном месте для gcc. И это при большом количестве патчей.

madcore ★★★★★
()

> Сборка ядра в icc позволяет обеспечить прирост производительности некоторых подсистем ядра до 40%

А как она сказывается на размере ядра и потребллении памяти?

question4 ★★★★★
()
Ответ на: комментарий от question4

>А как она сказывается на размере ядра и потребллении памяти?

Радикальных изменений в размере быть не должно. А память в ведре всегда выделяется явным образом, т.е. измениться ничего не должно.

madcore ★★★★★
()
Ответ на: комментарий от madcore

> Радикальных изменений в размере быть не должно.

Во многих тестах ICC стабильно даёт бинарники на 10-20% быстрее, чем GCC, и на 30-40% больше. Интересно, какая будет разница для блоков, где скорость отличается на 40%.

> А память в ведре всегда выделяется явным образом, т.е. измениться ничего не должно.

Имхо, разница в объёме из-за размера не данных, а кода. Или в ядре и его объём как-то фиксируют?

question4 ★★★★★
()

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

>игровых


Ahahahahah oh lol...

nikolayd
()
Ответ на: комментарий от question4

>Во многих тестах ICC стабильно даёт бинарники на 10-20% быстрее, чем GCC, и на 30-40% больше. Интересно, какая будет разница для блоков, где скорость отличается на 40%.

При компиляции линуксового ядра icc не может себя значительно проявить. Те же SIMD-инструкции, где он силен, в ядре прозрачно использовать нельзя. Та же оптимизация между разными объектами компиляции недоступна, и тд..

>Имхо, разница в объёме из-за размера не данных, а кода. Или в ядре и его объём как-то фиксируют?


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

madcore ★★★★★
()
Ответ на: комментарий от question4

> Во многих тестах ICC стабильно даёт бинарники на 10-20% быстрее

ты знаешь, я ни разу не видел ситуаций, когда ядро потребляет более 3% CPU time :-)

no-dashi ★★★★★
()
Ответ на: комментарий от madcore

> Размер кода ядра совершенно неинтересен

Авотнихера. Были замеры, что ядро, собранное с -Os, быстрее собранного с -O2 - за счет того, что оно не засоряет кэш.

tailgunner ★★★★★
()
Ответ на: комментарий от no-dashi

> ты знаешь, я ни разу не видел ситуаций, когда ядро потребляет более 3% CPU time :-)

Будет не 3, а 2,15%. "Скока ни есть, нам всё хватит" :)

Просто интересно, чего там можно достичь.

question4 ★★★★★
()
Ответ на: комментарий от no-dashi

>ты знаешь, я ни разу не видел ситуаций, когда ядро потребляет более 3% CPU time :-)

Есть такое магическое слово, как NFS на гигабитной сети :)

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.