Это очень вряд-ли, так как даже для определённой версии ядра требуется определённая версия gcc. И синтаксиc ассемблера у интела иной чем у gcc. В общем утопия.

http://software.intel.com/en-us/articles/intel-c-compiler-for-linux-kernel-bu...
гугель он могуч.

>микросовтовский компилятор делает лучший код чем интеловский компилятор

толстенно. по всем тестам в Сети их компилятор сливает в ноль.

P.S. Да, соберется после пары патчей. google://linuxDNA

микросовтовский компилятор делает лучший код чем интеловский

За это стоило бы «коллеге» дать в глаз.

интеловский компилятор для интеловских камней лучше

попробуй-попробуй непонятно чем ядро скомпилировать. Сомневаюсь, что оно вообще заведется (если, конечно, скомпилируется).

А вот я тут еще услышал что gcc - компилятор не очень. Я не знаю правда это или нет. Это правда? Вот и подумал что собрав ядро интеловским компилятором у меня производительность будет больше.

Вообщем, сегодня попробую собрать им ядрышко, о результатах отпишусь.

LinuxDNA

А вот я тут еще услышал что gcc - компилятор не очень.

От кого такие сведения-то поступают?

От кого такие сведения-то поступают?

Это ему, наверное, вышеуказанный «коллега»-вантузятник мозги промыл.

>Это правда?

конечно правда. серьезный софт только интелом собираю

>Сомневаюсь, что оно вообще заведется

у чуваков заводиться и работает, прирост производительности на некоторых модулях до 40%, в среднем - ~10%

Сильви вроде пробовала генту собирать с icc. и вроде даже оно работало. насчет ведра - врядли, емнип, там есть код заточенный под «фишки» gcc.

>За это стоило бы «коллеге» дать в глаз.

ну mingw та еще поделка

>И синтаксиc ассемблера у интела иной чем у gcc

откуда трава?

ничего кроме отдельных пакетов (вручную) не собирала, и то отказалась от этого в пользу стабильности, с ICC стабильностью увы особо и не пахнет, очень многие пакеты слишком GCCизированы

> прирост производительности на некоторых модулях до 40%, в среднем - ~10%

О, это просто прекрасно!!! Ведь по данным vmstat время, процессорное время, съеденное кодом ядра, составляет аж от 0.1 до 4 процентов (а в среднем около 0.5%), так что, даже 100% прирост производительности будет укладываться в погрешность измерения :-)

P.S.: вы про эффект плацебо слышали?

на сайте LinuxDNA вроде был список пакетов, которые работают

добавлю:

тем более тормоза от IOwait никуда не уйдут, а именно они являются основной причиной раздражения

зато шанс получить нестабильность и новые глюки возрастает достаточно сильно

http://www.gentoo-wiki.info/HOWTO_ICC_and_Portage


там только патчи для ядра и ссылка на гентушную вики

>очень многие пакеты слишком GCCизированы

1. собирается и отлично работает Qt

2. вроде бы все KDE поддерживает интел

вообще все что портировано на другие платформы как правило собирается ICC и более-менее работает, с Qt-KDE были проблемы с компоновкой, cmake KDE ругается на -fvisibility=hidden отсутствующее в qt, хотя да, работало, но и без icc я бы не сказала что kde или qt тормозит

PS:
патчсет: dna-2.6.32.9-ia32.patch (new 32bit patch)
ядро: 2.6.32.9


patching file arch/x86/include/asm/percpu.h
Hunk #2 FAILED at 104.
Hunk #4 FAILED at 149.
Hunk #5 FAILED at 169.
Hunk #6 FAILED at 206.
patching file fs/compat_ioctl.c
Hunk #1 FAILED at 1660.
patching file include/linux/compiler-gcc4.h
Hunk #1 FAILED at 52.

вообщем выглядит не очень хорошо ) может быть как-нибудь в виртуалбоксе посмотрю,а на реальных железках пусть работает обычное

Собирал дженту, примерно 70% icc, до ядра руки не доходили — овчинка выделки не стоит.

>откуда трава?
C icc дела не имел, если оно и может at&t то вроде как не полностью, хотя возможно не прав.

оно прекрасно переваривает и GCCизмы в том числе, кстати одна из зависимостей ICC - GCC, он его иногда как препроцессор использует

Я тоже думал пощупать icc красноглазия и общего развития для, передумал. Похоже, что для обычного пользователя овчинка выделки не стоит.

http://m0nochr0me.blogspot.com/2010/02/intel-c-compiler-archlinux.html

http://habrahabr.ru/blogs/linux/83324/

абсолютно не стоит, при 10-15% приросте производительности есть шанс получить достаточно неприятных глюков даже если все соберется и поначалу кажется что будет работать, mplayer например (некоторые ревизии) у меня отказывались открывать поток из сети, хотя локальные файлы нормально. Arora - не показывает историю посещений (нет дат в меню), Gimp - некоторые картинки открываются как пустой фон, и это все _собралось_ причем собралось нормально (!)

>оно прекрасно переваривает и GCCизмы в том числе, кстати одна из зависимостей ICC - GCC, он его иногда как препроцессор использует
Идиотизм, для одного компилятора нужен другой.

Clang тоже использует GCC как ассемблер и компоновщик,
ICC - как препроцессор, если использован флаг -gcc или -pragma-optimization-level=GCC

Премного благодарен

Вообще-то наша дисскуссия имеет и практический смысл. Немало людей, умеющих пользоваться поиском, сэкономит время на более полезное (красноглазие). Популярность ЛОРа играет свою роль. Немало подчерпнул отсюда в своё время. Не примите за лесть, как в прошлый раз, но Ваши комментарии всегда уместны и приносят немало пользы.

>ICC - как препроцессор, если использован флаг -gcc
Для чего?

А где препроцессор?

Анонимус подтверждает, что не нужно.

О Великий Анонимус, я всегда хотел быть больше, чем кажусь

По моему, это конец icc среди красноглазых смертных, нет? Надеюсь на реинкарнацию, тем не менее. P.S. Штеуд всегда любил.

http://www.ibm.com/developerworks/ru/library/l-gcc-hacks/
Про LinuxDNA не был в курсе, интересная наверно вещица.

>оно прекрасно переваривает и GCCизмы в том числе, кстати одна из зависимостей ICC - GCC, он его иногда как препроцессор использует
Ой ли все? Почему ядро и прибито гвоздями к версии gcc, что эти измы не слабо отличаются в версиях. Про препроцессор gcc так и не понял, нафик он нужен icc? По-моему геморрой только, профита не видно.

icc поддерживает диалекты инлайнового ассемблера gcc и msvc (но два диалекта не могут присутствовать в одном файле)

-gcc по дефолту включен. Т.е., если в программе заложены ифдефы на версию GCC, с ICC все заработает. Версия GCC подставляется из системы

Насчет препроцессора - вряд ли, результаты -E у них отличаются, по крайней мере, форматированием строк. А вот заголовки от gcc использует, в отличие от того же сана, ибо interoperability

Препроцессор-то фигня, его задача тупа до безобразия. Экстеншены - тут весь геморрой.

libstdc++ обязательно
а как иначе еще совместимость обеспечивать?)

да, забыл)

что касается -fvisibility=hidden, то в qt эта опция включена для icc по дефолту, в кедах же только для GCC. Если интересно, могу потом закинуть фрагмент CMakeLists.txt, делающий кошерные флаги для интела

>в qt эта опция включена для icc по дефолту, в кедах же только для GCC

в том то и дело что материлось при сборке только kde
CMakeLists.txt можете не искать особенно, во-первых пересобирать скорее всего не буду, во-вторых флажки я форсирую через wrapper )

Вот «красноглазым смертным» он как раз и не нужен. Им обычно компиляют программы для всяких долгих расчётов, когда эти 10% хоть что-то значат. Для ядра, всякой гуйни, консольных утилит и прочего ширпотреба – выигрыш никакой, а геморроя много.

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

Хотя, если честно, за написание кода, который не собирается или не работает с отличными GCC компиляторами, надобно бы руки отрывать.

>Хотя, если честно, за написание кода, который не собирается или не работает с отличными GCC компиляторами, надобно бы руки отрывать.


около месяца переписывалась (не очень активно) с автором xz-utils, по поводу ошибок декомпрессии , если собирать xz-utils с помощью ICC.
Ошибку он нашел, исправил, прошло 2 месяца...



make[2]: Entering directory `/tmp/xz/tests'
PASS: test_check
test_stream_flags.c:55: !(test_header_decoder(LZMA_OK))
/bin/sh: line 5: 17299 ABRT/IOT trap ${dir}$tst
FAIL: test_stream_flags
test_filter_flags.c:122: decoded->start_offset == options.start_offset
/bin/sh: line 5: 17304 ABRT/IOT trap ${dir}$tst
FAIL: test_filter_flags
test_block_header.c:92: lzma_block_header_decode(&decoded_options, NULL, buf) == LZMA_OK
/bin/sh: line 5: 17309 ABRT/IOT trap ${dir}$tst
FAIL: test_block_header
PASS: test_index
Good file failed: ./files/good-0-empty.xz
FAIL: test_files.sh
test_compress.sh:
generated_abc../src/xz/xz: tmp_compressed: Compressed data is corrupt
Decoding failed: -1 compress_generated_abc
FAIL: test_compress.sh
=========================================
5 of 7 tests failed
Please report to lasse.collin@tukaani.org


что-то не хочу я ему опять писать уже...

Ну если у автора кривые руки, то остается либо исправлять все самостоятельно, либо забить.

>Хотя, если честно, за написание кода, который не собирается или не работает с отличными GCC компиляторами, надобно бы руки отрывать.

...Хотя бы из-за того, что такой код может по-другому вести себя со свежей версией GCC