LINUX.ORG.RU

Релиз Intel Studio XE 2011

 , ,


0

1

Сравнительно недавно корпорация Intel провела ребрендинг и релиз своих программных продуктов для разработчиков на платформах IA-32 (x86), Intel-64 (x86_64).

Вышли Intel® Parallel Studio XE 2011 for Linux (включает Intel® C++ Composer XE (ранее Intel C/C++ compiler), Intel® Fortran Composer XE (ранее Intel Fortran Compiler), Intel® VTune™ Amplifier XE (инструмент для профилирования), Intel® Inspector XE (инструмент для отладки памяти приложения и потоков)), а также версия без компилятора Fortran — Intel® C++ Studio XE 2011 for Linux.

Помимо интегрированных пакетов вышли и обновления индивидуальных компонентов:

  • Intel® Fortran Composer XE 2011 for Linux v 12.0 — включает компилятор фортран и Math Kernel Library;
  • Intel® C++ Composer XE 2011 for Linux (ранее Intel C/C++ compiler) — включает ICC v12.0.0, а также IPP, MKL и TBB;
  • Intel® Math Kernel Library (Intel® MKL) for Linux v10.3 — библиотека оптимизированных математических функций;
  • Intel® Integrated Performance Primitives (Intel® IPP) for Linux v7.0 - библиотека оптимизированных функций шифрования, компрессии и обработки мультимедиа, а также создания многопоточных приложений (TBB v3.0).

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

Среди новшеств:

  • Значительно повышено быстродействие результирующего кода в тестах Spec 2006;
  • Добавлена поддержка процессоров Intel Sandybridge;
  • Улучшена поддержка расширений AVX;
  • Улучшена поддержка стандарта Fortran 2003, добавлены элементы поддержки Fortran 2008 (Co-Array, автопараллелизация, поддержка расширений AVX);
  • В «Studio»-продукты добавлены инструменты для анализа безопасности кода (подробности по SSA).

>>> Подробности

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: Dendy (всего исправлений: 4)

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

>Интел считают что учиться нужно платно...

Интел считает что учиться можно и на чем нить попроще.

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

возможно, clang в плане диагностики весьма неплох

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

Староваты будут, не хочу самому патчи на бтрфс накладывать, честней - не осилю, а в последних ядрах мне показалась ускорилось это дело всё

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

>Research к обучению каким боком?

Я привел условие самое важное, которое позволяет использовать софт под non-commercial лицензией. Кроме того, academic - широкое понятие. Если интересно, то читать здесь. Там ответы для студента, профессора и т.д. http://software.intel.com/en-us/articles/non-commercial-software-faq/

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

>начиная с версии 11 - нет

Ну не знаю, не знаю. У меня на AMD Opteron(tm) Processor 885 все так же Intel(R) Fortran Intel(R) 64 Compiler Professional Version 11.1 Build 20091130 после ifort -O3 -xSSE3 и ./a.x несколько месяцев назад выплевывал

Fatal Error: This program was not built to run on the processor in your system. The allowed processors are: Intel(R) Pentium(R) 4 and compatible Intel processors with Streaming SIMD Extensions 3 (SSE3) instruction support.

Хотя Opteron 800-series «Egypt» (E1 & E6, 90 nm) * All models support: MMX, SSE, SSE2, SSE3, Enhanced 3DNow!, NX bit, AMD64

После патча в __intel_cpu_indicator_init

s/817df047656e75/f745f000000000/g

s/817de8696e6549/f745e800000000/g

s/817de06e74656c/f745e000000000/g

работает как ни в чем не бывало.

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

тесты GMPBench 0.2 ( полный выхлоп тут - http://paste.debian.net/100405/ )

C2D E8400
GCC 4.5.2pre (O3 -msse4.1 -mfpmath=sse -march=core2 -fomit-frame-pointer)
vs
ICC 12.0.0 (O3 -ip -xSSE4.1 -fomit-frame-pointer)

оценка в попугаях ( больше - лучше )
GCC:
GMPbench.base.multiply 7686.8
GMPbench.base.divide 9367.4
GMPbench.base.gcd 1980.5
GMPbench.base.gcdext 1170.8
-------------> GMPbench.base 4786.3

GMPbench.app.rsa 808.52
GMPbench.app.pi 11.404
--------------> GMPbench.app 96.024
===>GMPbench: 677.94

ICC:
GMPbench.base.multiply 7769.2
GMPbench.base.divide 9805
GMPbench.base.gcd 1969.8
GMPbench.base.gcdext 1164.6
-------> GMPbench.base 4868.2

GMPbench.app.rsa 803.49
GMPbench.app.pi 11.518
--------> GMPbench.app 96.2
===>GMPbench: 684.34

вообщем тест-числодробилка, хороший отрыв показал icc только на делении чисел,
в остальном же прирост достаточно скромный

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

речь шла о том , что интел проверяли вендора до версии 11
и для AMD пускали код по неоптимизированой ветке,
т.е. если вы собрали -mia32 -axP , то на AMD работала mia32 ветка, несмотря на наличие SSE3 и возможности работы по -axP (в современной версии -axSSE3 или -axO )

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

попробую конечно. Спасибо. Хотя для наших АМДшек я уже по своим тестам понял что gfortran -O3 -march=amdfam10 -funroll-all-loops -fprefetch-loop-arrays ничем не хуже, а местами даже лучше ifort с полной оптимизацией: ifort -O3 -ip -ipo -static -xP -finline-functions -funroll-loops (которая без патча там вообще не включалась).

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

>речь шла о том , что интел проверяли вендора до версии 11

Я знаю о чем речь:) Насмотрелся когда на АМД кластерах наша задача считалась месяц вместо 10 дней на интелах:)

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

Мне известно о таких утилитах. См. например http://www.swallowtail.org/naughty-intel.shtml

История эта очень громкая, дошло даже до антимонопольного комитета. http://www.theinquirer.net/inquirer/news/1567108/intel-compiler-cripples-code...

Агнер Фог тоже долго с ней боролся http://www.agner.org/optimize/blog/read.php?i=49

Как я и говорю, мы решили тем, что взяли gfortran, который для амдшных оптеронов и феномов ничем не хуже интеловского компилятора ifort. В некоторых случая gfortran даже выигрывает на AMD CPU по сравнению с ifort. На интеловских ксеонах -нет, тут конечно intel compiler нету равных. Особенно как в моем случае где 10% прироста производительности это может быть и несколько дней работы для среднего кластера.

terminat0r
()

А какие компиляторы си/си++ выдают наиболее оптимизированный код? gcc/g++ или интеловские? или другие?

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

Я думаю это связано с тем что большинство GNU кода затачивается под gcc И даже не затачивается, а изначально разрабатывается под требования gcc

anonymous
()

спасибо! это очень хорошая новость. Загружаю инстоляторы

dimsonchik
()

Отлично. Жаль, что Фортран пока не нужен. Когда-то матмодели на нём писал.

Deleted
()

Кстати, а интеловский композятор умеет делать бинарники, не требующие его родного рантайма (и при этом без плясок с бубуном)? А то я когда в последний раз с ним игрался на числордобильных задачах, это немного напрягало.

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

> А для амд?

Если он перестал преднамеренное замедлять исполнение на АМД (см. выше ссылки), то вероятно тоже он, но лучше проверять конкретные случаи.

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

>Куда академическое вставили они, с моего уровня понимания - не понятно.

Это коммерческое использование научными группами (например, если ты получаешь деньги по грантам, то формально ты не можешь юзать ifort по некоммерческой лицензии)

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

>Если он перестал преднамеренное замедлять исполнение на АМД

он просто «выключал» CPU dispatching)

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

>А для амд?

Pathscale, конечно же) Сановкий тоже ниче (если мы о фортране)

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

>интересно им можно полностью ядро с де собрать или всё на gcc завязло

гугли Linux DNA. KDE тоже вроде можно

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

>Если я скачиваю компилятор, то он должен и называться компилятором, а не композером.

+1

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

>с либами собранными гцц линковаться не получится?

получится, они бинарно совместимы (это тебе не сановский:)

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

>на всякий случай лучше все же собирать с ключами -gcc

это только для gcc-измов, на бинарную совместимость не влияет

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

>Какие то странные зависимости

На 64-битной Мандриве он кстати ни при каких условиях не сможет найти все зависимости) Интеловцы советуют ставить из рпмок, они там же

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

как раз 20% и показывает.

С Open64 на АМД не сравнивали? Особенно было бы интересно на феноме-2 со специфическими АМДшными расширениями (лонгдаблы там, ...).

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

>У меня на AMD Opteron(tm) Processor 885 все так же Intel(R) Fortran Intel(R) 64 Compiler Professional Version 11.1 Build 20091130 после ifort -O3 -xSSE3 и ./a.x несколько месяцев назад выплевывал

потому что маны надо читать. а в мане написано, что все -x опции только для интеловских процов. юзай -msse3

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

Да, есть такой глюк, хотя 10я версия нормально взлетала. Там есть non-interactive install, который всё может поставить без вопросов. Надо install.sh запускать с каким-то ключем и указать конфиг в котором перечислены продукты, которые надо установить.

Reset ★★★★★
()

Когда-то использовал 9-тую версию, но уже 1,5 года собираю код ГФортраном. Особых тормозов не заметил. Реально в интеле было удобно использовать Numerical_recipies (IMSL по-старому), но он всё равно платный. Вместо него пришлось качать и подключать целый ряд библиотек и модулей: Lapack, FFTW3 и всякую ерунду помельче.

Что касается стандарта 2003, то сам этот стандарт весьма спорный: пытаться в хороший старый процедурный язык внести зачем-то ООП в весьма ущербной и неудобной форме довольно глупо. Лучше было пересмотреть концепцию и подобно тому, как f77 оставлен под видом Fortran fixed form, а на его место пришёл f90/f95, так же разработать новый более удобный синтаксис и подтянуть многие свойства. Это же кошмар, в языке до сих пор нету даже строк произвольной длины, если не пользоваться левыми расширениями.

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

>Кстати, а интеловский композятор умеет делать бинарники, не требующие его родного рантайма (и при этом без плясок с бубуном)?

ты хочешь чего-то странного. Ни один компилятор такого не умеет. Но можно слинковать рантайм статически

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

Из rpm'ок не поможет, ибо после разворачивания выбранных rpm'ок запускает мега-пост-инсталл скрипт, который правит пути в .sh'никах. Если руками разворачивать, то пути придется править самому.

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

>скрипт после разворачивания rpm'ок запускает мега-пост-инсталл скрипт, который правит пути в .sh'никах. Если руками разворачивать, то пути придется править самому.

хм, никогда не ставил в недефолтный путь. да и без всех этих .sh пользоваться можно)

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

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

оу, Сильви повышает ЧСВ :)

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

на мой взгляд, такое положение ICC связано с упорством ГГМнутых, не желающих его использовать. Всегда проще сказать, что GCC свободен, а посему божественнен, и если с ним собирается, то все ок.

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

на мой взгляд, такое положение ICC связано с упорством ГГМнутых, не желающих его использовать. Всегда проще сказать, что GCC свободен, а посему божественнен, и если с ним собирается, то все ок.

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

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

тогда много всего в bashrc придется писать, а так у меня там всего две строки

source /opt/intel/Compiler/11.1/069/bin/iccvars.sh intel64
source /opt/intel/Compiler/11.1/069/bin/ifortvars.sh intel64
Reset ★★★★★
()
Ответ на: комментарий от Orlusha

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

То есть ты считаешь, что большинству программ нафиг не сдалась поддержка x86 и x86_64?

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

приэтом заметь, что код, компилирующийся ICC (если не пользоваться интеловскими прагмами, или, не дай бог, майкрософтовским диалектом асма), будет компилироваться и GCC, но не наоборот

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

То есть ты считаешь, что большинству программ нафиг не сдалась поддержка x86 и x86_64?

Я считаю, что большинству программ нафиг не сдалось заведомое отсутствие поддержки других архитектур, помимо x86/x64 и IA-64.

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

>Я считаю, что большинству программ нафиг не сдалось заведомое отсутствие поддержки других архитектур, помимо x86/x64 и IA-64.

см. выше

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

приэтом заметь, что код, компилирующийся ICC (если не пользоваться интеловскими прагмами, или, не дай бог, майкрософтовским диалектом асма), будет компилироваться и GCC, но не наоборот

...и получается миленькая ситуация, когда пишешь под ICC, но если хочешь совместимости с GCC — то надо отлаживать на обоих в полном объёме, включая покрытие и функциональные тесты... Бррр...

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

зато не приходится разбирать сообщения об ошибках по пять минут :)

а если в тулчейне для твоей железки другая версия GCC, например 2.95? Я бы не сказал, что GCC 4 и 2 совместимы лучше, чем <любая другая пара компиляторов>

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