LINUX.ORG.RU
Форум — General  

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


0

0

Здравствуйте. Недавно при обсуждении компиляторов с коллегой узнал мнение что микросовтовский компилятор делает лучший код чем интеловский компилятор. Полистав сайты в интернете нашел мнение что интеловский компилятор для интеловских камней лучше. А что может по этому поводу сказать глубокоуважаемая публика ЛОРа? Что делает лучший код?
Это я решил попробовать собрать ядро с интеловским компилятором. Полистав сайты в интернете нашел мнение что ядро им не соберется. Может ли мне кто-то сказать точно, собирется или нет? Кто-то уже им собирал?

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

Booster ★★
()

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

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

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

devl547 ★★★★★
()

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

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

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

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

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

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

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

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от facelift

>Это правда?

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

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

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

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

annulen ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

добавлю:

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

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

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

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

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

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

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

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

Sylvia ★★★★★
()

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.

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

Sylvia ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

kraftello ★★★★★
()
Ответ на: комментарий от Booster 
-gcc      Predefine the "__GNUC__", "__GNUC_MINOR__", and 
          "__GNUC_PATCHLEVEL__" macros (DEFAULT)

-gcc-name=<name>
          name and location of gcc if not where expected
-gxx-name=<name>
          name and location of g++ if not where expected
-gcc-version=<version>
          specify the <version> of gcc compatibility.  Default value matches
          gcc version installed.  Major/Minor versions listed but patch
          levels (i.e. 345) are permissible
            320 - gcc 3.2.x compatibility
            330 - gcc 3.3.x compatibility
            340 - gcc 3.4.x compatibility
            400 - gcc 4.0.x compatibility
            410 - gcc 4.1.x compatibility
            420 - gcc 4.2.x compatibility
-fabi-version=<val>
          directs the compiler to select a specific ABI implementation
            0 - most recent ABI implementation
            1 - g++ 3.2 compatible ABI implementation
            2 - most conformant ABI implementation
Sylvia ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

annulen ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

>Хотя, если честно, за написание кода, который не собирается или не работает с отличными 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


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

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

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

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

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

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

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