Intel C Compiler | Настройка, пакеты и т.д.

Всем привет!

Особенный привет тем, кто юзает сабж.
Хочу спросить - юзабельный ли сабж, стоит ли попробовать? У меня Core 2 Duo, вроде подходит. И система ~amd64.
Еще интересует - какие трудности будут ожидать на пути, как стоит организовать систему - собираем всё icc, а конкретные пакеты gcc - или наоборот? Какие пакеты 100% не собираются/не должны собираться icc ?
Вообще, лучше ли icc, чем gcc, насколько даёт прирост и где? Только на вопрос "чел лучше и лучше ли" хотелось бы логичных доводов, а не эмоций.

Вообщем предлагаю порубиться на эту тему. Описание подводных камней, думаю, не мне одному пригодится. :-)

На хабре пару-тройку месяцев

На хабре пару-тройку месяцев назад нарисовалась статейка
По-моему, неплохая.

Истин имперских звезда засияет.

(:

Nirvandil написал(а):
На хабре пару-тройку месяцев назад нарисовалась статейка
По-моему, неплохая.

Хабр... ксакеп... линуксоргру...

Ссылка "доставила":

Цитата:
Согласитесь, весьма неплохие результаты.
Конфигурация компьютера, на котором производилась проверка: Intel Core 2 Duo T7250 @ 2.00 GH

было

старая тема тут
Хабр это в общем-то перевод вики

TODO по теме
- все еще отсутствуют списки того что можно (и нужно) и что нельзя (небезопасно) собирать icc
- отсутствует возможность еще более детального тюнинга, когда каждому пакету можно задавать специальные флаги (напр. Qt)
- отсутствует описание влияния вот этого ядра http://www.linuxdna.com/ на гибридную систему. Само ядро в вакууме выглядит не столь выигрышным против gcc-4.5'шного.
- попытки расширить список компиляторов clang'ом и компилятором от sun (состояние мне не известно)...

Цитата:
порубиться

хм..

- все еще отсутствуют списки

- все еще отсутствуют списки того что можно (и нужно) и что нельзя (небезопасно) собирать icc

стандартный опенсорц - кто может составить, тому некогда ( он и так занят) , кто не может - пишет на лорах и в хакерах.

- отсутствует возможность еще более детального тюнинга, когда каждому пакету можно задавать специальные флаги (напр. Qt)

в Гентоо этой возможности 100 лет в обед - и флаги, и вообще любые переменные окружения для каждой версии любого пакета.
Матчасть надо знать.

- отсутствует описание влияния вот этого ядра http://www.linuxdna.com/ на гибридную систему

см. п1. это если на уровне писания тестов, а не скорости кликанья мышой в FF.

- попытки расширить список компиляторов clang'ом и компилятором от sun (состояние мне не известно)

и все таки данные компиляторы - скорее такие же нишевые продукты, как и сабж. clang правда, в отличии от сабжа таки только себя и собирает :) ( ну не надо тут про фряху), второй в {configure,Makefile}.am/in вообще не встречал.
когда они заработают на чем то отличном от ia32 - тогда и можно о чем то разговаривать.

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

Цитата: в Гентоо этой

Цитата:
в Гентоо этой возможности 100 лет в обед - и флаги, и вообще любые переменные окружения для каждой версии любого пакета.
Матчасть надо знать.

имелся в виду опять-таки список пакет-флаги, ибо нек. пакетам необходимы флаги послабее и т.д.

Цитата:
стандартный опенсорц - кто может составить, тому некогда ( он и так занят) , кто не может - пишет на лорах и в хакерах

sad but true

простите мою безграмотность

slepnoga написал(а):
razum2um написал(а):
- отсутствует возможность еще более детального тюнинга, когда каждому пакету можно задавать специальные флаги (напр. Qt)

в Гентоо этой возможности 100 лет в обед - и флаги, и вообще любые переменные окружения для каждой версии любого пакета.
Матчасть надо знать.

это вы про /etc/portage/env/class/package ? Флаги для ICC, я так понимаю, там тоже можно задавать..?

Я собираю им архиваторы,

Я собираю им архиваторы, прирост в скорости на 200 мб архивах где то на 2-3 секунды быстрее :)

Стоит попробывать собрать им кодеки(ffmpeg, ogg, ...) ну там где время работы программы упирается в процессор.
И еще если программа это всего лишь обертка ( GUI, ГУИ ) пересобирать надо не её, а то что она "оборачивает" :)

Working on Gentoo Linux for Asus P535 and Qtopia :-)

/

oleg_kaa написал(а):
Я собираю им архиваторы, прирост в скорости на 200 мб архивах где то на 2-3 секунды быстрее :)

На каком процессоре? GCC с Graphite?

oleg_kaa написал(а):
И еще если программа это всего лишь обертка ( GUI, ГУИ ) пересобирать надо не её, а то что она "оборачивает" :)

И еще мир не ограничен одной лишь x86.

P.S. в gcc 4.5.0. добавлена поддержка плагинов позволяющих менять функциональность компиляторов без пересборки GCC (привет, clang)

Core 2 Duo Ну я не против

Core 2 Duo

Ну я не против gcc, я даже за :)) Но icc попробывать стоит :)

Working on Gentoo Linux for Asus P535 and Qtopia :-)

/

oleg_kaa написал(а):
Core 2 Duo

Почему то не удивлен. На EM64T GCC с Graphite порвет icc. IA32 и Itanium2, там да, icc опережает, на 5-10 % быстрее (в некоторых задачах).
И еще: целочисленный тип int128_t и 64-битное умножение icc умеет или нет?

oleg_kaa написал(а):
Но icc попробывать стоит :)

Не раньше, чем откроют его исходный код и PaX-team его сможет пропатчить =)
P.S. ничего не имею против icc, но:
0. он собирает не все, даже если и собирает, то не факт, что это может работать корректно
1. в случае использования !Intel процессоров имеются известные нарекания на производительность кода
2. капитан нам намекает, что icc не бесплатен (stages и прочее им собирать нельзя)

Аминь

Аминь

Working on Gentoo Linux for Asus P535 and Qtopia :-)

такие дела

Попробовал я этот icc. Пробовал на media-libs/flac.
Вот какие результаты: icc-шный код тестовай wav-файл сконвертировал в flac за 43 секунды; gcc-шный - за 59. Тестировал в tmpfs и cpu governor=performance.
Флаги:
ICC="-mssse3 -xSSSE3 -O2"
(счас будете наезжать, смеяться и ругать)
GCC="-O2 -march=core2 -pipe -mfpmath=sse -mmmx -msse -msse2 -msse3 -mssse3 -mno-3dnow --param l1-cache-size=32 --param l1-cache-line-size=32 --param l2-cache-size=2048 -g0 -Wno-all -floop-interchange -floop-strip-mine -floop-block -ftree-loop-linear -fno-guess-branch-probability"

Есть два "но".
1. ICC не захотел работать, пока не установил переменную окружения LANGUAGE=C. Зато команды типа 'man 123' стали отвечать на англицком. Неприятно.
2. После сборки конкретно media-libs/flac получил вот это:

QA: other
QA Notice: The following files contain writable and executable sections
 Files with such sections will not work properly (or at all!) on some
 architectures/operating systems.  A bug should be filed at
 http://bugs.gentoo.org/ to make sure the issue is fixed.
 For more information, see http://hardened.gentoo.org/gnu-stack.xml
 Please include the following list of files in your report:
 Note: Bugs should be filed for the respective maintainers
 of the package in question and not .
!WX --- --- usr/lib64/libFLAC.a:bitmath.o
!WX --- --- usr/lib64/libFLAC.a:bitreader.o
!WX --- --- usr/lib64/libFLAC.a:bitwriter.o
!WX --- --- usr/lib64/libFLAC.a:cpu.o
!WX --- --- usr/lib64/libFLAC.a:crc.o
!WX --- --- usr/lib64/libFLAC.a:fixed.o
!WX --- --- usr/lib64/libFLAC.a:float.o
!WX --- --- usr/lib64/libFLAC.a:format.o
!WX --- --- usr/lib64/libFLAC.a:lpc.o
!WX --- --- usr/lib64/libFLAC.a:md5.o
!WX --- --- usr/lib64/libFLAC.a:memory.o
!WX --- --- usr/lib64/libFLAC.a:metadata_iterators.o
!WX --- --- usr/lib64/libFLAC.a:metadata_object.o
!WX --- --- usr/lib64/libFLAC.a:stream_decoder.o
!WX --- --- usr/lib64/libFLAC.a:stream_encoder.o
!WX --- --- usr/lib64/libFLAC.a:stream_encoder_framing.o
!WX --- --- usr/lib64/libFLAC.a:window.o
!WX --- --- usr/lib64/libFLAC.a:ogg_decoder_aspect.o
!WX --- --- usr/lib64/libFLAC.a:ogg_encoder_aspect.o
!WX --- --- usr/lib64/libFLAC.a:ogg_helper.o
!WX --- --- usr/lib64/libFLAC.a:ogg_mapping.o
!WX --- --- usr/lib64/libFLAC++.a:metadata.o
!WX --- --- usr/lib64/libFLAC++.a:stream_decoder.o
!WX --- --- usr/lib64/libFLAC++.a:stream_encoder.o

И вот как бы не радостно видеть такое.

Поэтому вопрос к юзающим icc, да и не только - это ^ нормально? К слову, после gcc такого нет.

Ну если в думаться в перевод

Ну если вдуматься в перевод то это не трагедия и не ошибка :)

Это всего лишь значит что в этих файлах есть самомодифицируемый код.

А в случае с ICC:
при запуске программа определяет процессор и его возможности и перестраивает себя так что бы выполнятся с максимальной скоростью

А gcc просто так не умеет/не делает

Working on Gentoo Linux for Asus P535 and Qtopia :-)

Ага )

Значит, можно доверить ICC компилять flac, и остальные возможные пакеты?

Все он не соберет, лично я

Все он не соберет, лично я доверяю архиваторы :) А так если перекодируешь видео часто, то пересобери либы отвечающие за кодирование видео

Working on Gentoo Linux for Asus P535 and Qtopia :-)

?

oleg_kaa написал(а):
Ну если вдуматься в перевод то это не трагедия и не ошибка :)

Это всего лишь значит что в этих файлах есть самомодифицируемый код.

Joanna Rutkowska об этом расскажите.
Это означает, что разработчики Intel не очень то озабочены безопасностью, да. Один только SMM чего стоит =)
А предупреждение означает, что код генерируемый icc не безопасен, такая вот оптимизация.

oleg_kaa написал(а):
А в случае с ICC:
при запуске программа определяет процессор и его возможности

Программа определяет или компилятор? А что тогда делает march=native?

oleg_kaa написал(а):
и перестраивает себя так что бы выполнятся с максимальной скоростью

А gcc просто так не умеет/не делает

Серьезно что ли? Уже переписали на lisp и у icc появился искусственный интеллект?

taaroa написал(а): Joanna

taaroa написал(а):
Joanna Rutkowska об этом расскажите.
Это означает, что разработчики Intel не очень то озабочены безопасностью, да. Один только SMM чего стоит =)
А предупреждение означает, что код генерируемый icc не безопасен, такая вот оптимизация.

Ну а кто сейчас может создавать безопасный код? Вот недавно gcc убирал проверки типа if(pointer == null) и в ядре появилась новая уязвимость :) К счастью её случайно обнаружили и закрыли :)

taaroa написал(а):
Программа определяет или компилятор? А что тогда делает march=native?

Это делается в runtime-режиме, если ты знаешь что это такое

taaroa написал(а):
Серьезно что ли? Уже переписали на lisp и у icc появился искусственный интеллект?

Причем тут ИИ? У интел есть несколько типов ядер, на каждом ядре один и тот же код может выполнятся по разному и с разной скоростью. В самом начале при запуске icc вставка просто выбирает оптимальный на её взгляд профиль (именно поэтому проблемы с не intel процессорами)

Working on Gentoo Linux for Asus P535 and Qtopia :-)

/

oleg_kaa написал(а):
Ну а кто сейчас может создавать безопасный код? Вот недавно gcc убирал проверки типа if(pointer == null) и в ядре появилась новая уязвимость :) К счастью её случайно обнаружили и закрыли :)

Только ссылки на CVE|GLSA принимаются.

oleg_kaa написал(а):
Это делается в runtime-режиме, если ты знаешь что это такое

Знаю, даже несмотря на то, что моя первая специальность весьма далека от программирования (02.04.00).

oleg_kaa написал(а):
taaroa написал(а):
Серьезно что ли? Уже переписали на lisp и у icc появился искусственный интеллект?

Причем тут ИИ? У интел есть несколько типов ядер, на каждом ядре один и тот же код может выполнятся по разному и с разной скоростью. В самом начале при запуске icc вставка просто выбирает оптимальный на её взгляд профиль (именно поэтому проблемы с не intel процессорами)

Вот об этом и писал|намекал выше, неоднократно.
P.S. с icc работал, но на другой OS (догадайтесь, какой?); еще раз: против icc ничего не имею, компилит? компилит, но ради пары процентов выигрыша в определенных приложения на определенных процессорах - не очень весомый аргумент для его использования, опять же, не означающий, что не стоит ставить эксперименты (так понятней?)

Пожалуста

Пожалуста http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1897

taaroa написал(а):
P.S. с icc работал, но на другой OS (догадайтесь, какой?); еще раз: против icc ничего не имею, компилит? компилит, но ради пары процентов выигрыша в определенных приложения на определенных процессорах - не очень весомый аргумент для его использования, опять же, не означающий, что не стоит ставить эксперименты (так понятней?)

Ну так о чем разговор тогда? :) Зачем тогда юзать генту? Процентов выигрыша в определенных приложения на определенных процессорах - не очень весомый аргумент для его использования?

Working on Gentoo Linux for Asus P535 and Qtopia :-)

хм...

oleg_kaa написал(а):
Пожалуста http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1897

В общем то, так и предполагал. =)
Ни одна из вариаций 0day использующих это на моих системах не работала.
Ниже приведенные так же не работали:
CVE-2009-1894 <- не работал
CVE-2008-0010 <- no
CVE-2008-0163 <- no
CVE-2008-0600 <- no

oleg_kaa написал(а):
taaroa написал(а):
P.S. с icc работал, но на другой OS (догадайтесь, какой?); еще раз: против icc ничего не имею, компилит? компилит, но ради пары процентов выигрыша в определенных приложения на определенных процессорах - не очень весомый аргумент для его использования, опять же, не означающий, что не стоит ставить эксперименты (так понятней?)

Ну так о чем разговор тогда? :) Зачем тогда юзать генту? Процентов выигрыша в определенных приложения на определенных процессорах - не очень весомый аргумент для его использования?

В Gentoo пришел с Debian|FreeBSD и совсем не по причине "процентов выигрыша", философия и основная идея Gentoo не в этом.

taaroa написал(а): В общем

taaroa написал(а):
В общем то, так и предполагал. =)
Ни одна из вариаций 0day использующих это на моих системах не работала.
Ниже приведенные так же не работали:
CVE-2009-1894 <- не работал
CVE-2008-0010 <- no
CVE-2008-0163 <- no
CVE-2008-0600 <- no

А что тут предполагать??? :)))))))) Я же сказал что дыру уже закрыли еще в 2009 году, а на дворе уже 2010 :)

taaroa написал(а):
В Gentoo пришел с Debian|FreeBSD и совсем не по причине "процентов выигрыша", философия и основная идея Gentoo не в этом.

Аминь!

Working on Gentoo Linux for Asus P535 and Qtopia :-)

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".