Intel C Compiler | Настройка, пакеты и т.д.
alex__ 18 апреля, 2010 - 02:38
Всем привет!
Особенный привет тем, кто юзает сабж.
Хочу спросить - юзабельный ли сабж, стоит ли попробовать? У меня Core 2 Duo, вроде подходит. И система ~amd64.
Еще интересует - какие трудности будут ожидать на пути, как стоит организовать систему - собираем всё icc, а конкретные пакеты gcc - или наоборот? Какие пакеты 100% не собираются/не должны собираться icc ?
Вообще, лучше ли icc, чем gcc, насколько даёт прирост и где? Только на вопрос "чел лучше и лучше ли" хотелось бы логичных доводов, а не эмоций.
Вообщем предлагаю порубиться на эту тему. Описание подводных камней, думаю, не мне одному пригодится. :-)
»
- Для комментирования войдите или зарегистрируйтесь
На хабре пару-тройку месяцев
На хабре пару-тройку месяцев назад нарисовалась статейка
По-моему, неплохая.
Истин имперских звезда засияет.
(:
Хабр... ксакеп... линуксоргру...
Ссылка "доставила":
было
старая тема тут
Хабр это в общем-то перевод вики
TODO по теме
- все еще отсутствуют списки того что можно (и нужно) и что нельзя (небезопасно) собирать icc
- отсутствует возможность еще более детального тюнинга, когда каждому пакету можно задавать специальные флаги (напр. Qt)
- отсутствует описание влияния вот этого ядра http://www.linuxdna.com/ на гибридную систему. Само ядро в вакууме выглядит не столь выигрышным против gcc-4.5'шного.
- попытки расширить список компиляторов clang'ом и компилятором от sun (состояние мне не известно)...
хм..
- все еще отсутствуют списки
стандартный опенсорц - кто может составить, тому некогда ( он и так занят) , кто не может - пишет на лорах и в хакерах.
в Гентоо этой возможности 100 лет в обед - и флаги, и вообще любые переменные окружения для каждой версии любого пакета.
Матчасть надо знать.
см. п1. это если на уровне писания тестов, а не скорости кликанья мышой в FF.
и все таки данные компиляторы - скорее такие же нишевые продукты, как и сабж. 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 ;)
Цитата: в Гентоо этой
имелся в виду опять-таки список пакет-флаги, ибо нек. пакетам необходимы флаги послабее и т.д.
sad but true
простите мою безграмотность
это вы про /etc/portage/env/class/package ? Флаги для ICC, я так понимаю, там тоже можно задавать..?
Я собираю им архиваторы,
Я собираю им архиваторы, прирост в скорости на 200 мб архивах где то на 2-3 секунды быстрее :)
Стоит попробывать собрать им кодеки(ffmpeg, ogg, ...) ну там где время работы программы упирается в процессор.
И еще если программа это всего лишь обертка ( GUI, ГУИ ) пересобирать надо не её, а то что она "оборачивает" :)
Working on Gentoo Linux for Asus P535 and Qtopia :-)
/
На каком процессоре? GCC с Graphite?
И еще мир не ограничен одной лишь 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 :-)
/
Почему то не удивлен. На EM64T GCC с Graphite порвет icc. IA32 и Itanium2, там да, icc опережает, на 5-10 % быстрее (в некоторых задачах).
И еще: целочисленный тип int128_t и 64-битное умножение 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 получил вот это:
И вот как бы не радостно видеть такое.
Поэтому вопрос к юзающим icc, да и не только - это ^ нормально? К слову, после gcc такого нет.
Ну если в думаться в перевод
Ну если вдуматься в перевод то это не трагедия и не ошибка :)
Это всего лишь значит что в этих файлах есть самомодифицируемый код.
А в случае с ICC:
при запуске программа определяет процессор и его возможности и перестраивает себя так что бы выполнятся с максимальной скоростью
А gcc просто так не умеет/не делает
Working on Gentoo Linux for Asus P535 and Qtopia :-)
Ага )
Значит, можно доверить ICC компилять flac, и остальные возможные пакеты?
Все он не соберет, лично я
Все он не соберет, лично я доверяю архиваторы :) А так если перекодируешь видео часто, то пересобери либы отвечающие за кодирование видео
Working on Gentoo Linux for Asus P535 and Qtopia :-)
?
Joanna Rutkowska об этом расскажите.
Это означает, что разработчики Intel не очень то озабочены безопасностью, да. Один только SMM чего стоит =)
А предупреждение означает, что код генерируемый icc не безопасен, такая вот оптимизация.
Программа определяет или компилятор? А что тогда делает march=native?
Серьезно что ли? Уже переписали на lisp и у icc появился искусственный интеллект?
taaroa написал(а): Joanna
Ну а кто сейчас может создавать безопасный код? Вот недавно gcc убирал проверки типа if(pointer == null) и в ядре появилась новая уязвимость :) К счастью её случайно обнаружили и закрыли :)
Это делается в runtime-режиме, если ты знаешь что это такое
Причем тут ИИ? У интел есть несколько типов ядер, на каждом ядре один и тот же код может выполнятся по разному и с разной скоростью. В самом начале при запуске icc вставка просто выбирает оптимальный на её взгляд профиль (именно поэтому проблемы с не intel процессорами)
Working on Gentoo Linux for Asus P535 and Qtopia :-)
/
Только ссылки на CVE|GLSA принимаются.
Знаю, даже несмотря на то, что моя первая специальность весьма далека от программирования (02.04.00).
Вот об этом и писал|намекал выше, неоднократно.
P.S. с icc работал, но на другой OS (догадайтесь, какой?); еще раз: против icc ничего не имею, компилит? компилит, но ради пары процентов выигрыша в определенных приложения на определенных процессорах - не очень весомый аргумент для его использования, опять же, не означающий, что не стоит ставить эксперименты (так понятней?)
Пожалуста
Пожалуста http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1897
Ну так о чем разговор тогда? :) Зачем тогда юзать генту? Процентов выигрыша в определенных приложения на определенных процессорах - не очень весомый аргумент для его использования?
Working on Gentoo Linux for Asus P535 and Qtopia :-)
хм...
В общем то, так и предполагал. =)
Ни одна из вариаций 0day использующих это на моих системах не работала.
Ниже приведенные так же не работали:
CVE-2009-1894 <- не работал
CVE-2008-0010 <- no
CVE-2008-0163 <- no
CVE-2008-0600 <- no
В Gentoo пришел с Debian|FreeBSD и совсем не по причине "процентов выигрыша", философия и основная идея Gentoo не в этом.
taaroa написал(а): В общем
А что тут предполагать??? :)))))))) Я же сказал что дыру уже закрыли еще в 2009 году, а на дворе уже 2010 :)
Аминь!
Working on Gentoo Linux for Asus P535 and Qtopia :-)