LINUX.ORG.RU

Intel C++ and Fortran Compilers 10


0

1

Корпорация Intel анонсировала выход новой десятой по счёту версии компиляторов C++ и Fortran, которые позволяют программистам использовать возможности параллелизма на уровне потока данных и работы нитей. Со стороны данных теперь поддерживается автовекторизация с использованием набора инструкций SSE4, которые появятся в процессорах архитектуры Penryn. Что касается параллелизма уровня нитей, компиляторы теперь поддерживают использование Intel Thread Building Blocks для автоматических оптимизаций, которые производятся одновременно с автовекторизацией. Об остальных нововведениях читайте по ссылкам.

Intel's Compilers Home Page: http://www.intel.com/cd/software/prod...

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

★★★★★

Проверено: cavia_porcellus ()

Для студентов по прежнему бесплатный?

[offtopic] Когда им полностью можно будет собрать gentoo

Dramokl
()

полезная вещь
на ней я поднял производительность hpl в 2.5 разаю

пошел смотреть и обновляться.

chocholl ★★
()

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

anonymous
()

>которые появятся в процессорах архитектуры Penryn.

прочитал Penguin, долго думал...
кста, а че за архитектура такая Penryn?

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

на самом деле даже больше чего Dont work with icc
но статеечка про 9, а с десятым попробовать нужно.

chocholl ★★
()

Не получилось у Интелев привести мир к тепловой смерти, теперь к глобальному сегфолту ведут, ага.

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

>а ней я поднял производительность hpl в 2.5 разаю

Что gcc опять отдыхает? Что такое hpl? Так я понял, что прикладные (свои) программы под Линукс icc можно собирать, а системные - отдыхают?

GladAlex ★★★★★
()

замечательная новость

как раз соберу на ноуте при помощи него все

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

HPL - A Portable Implementation of the High-Performance Linpack Benchmark for Distributed-Memory Computers

решение систем линейных уравнений высоких размерностей.
написаная с применением MPI
top 500 использует этот бенчмарк.

chocholl ★★
()

Ни разу не пробовал ICC, хотя слышал про него довольно много - как хорошего, так и не очень:). Реально ли он лучше g++? И как у него с поддержкой стандарта - будут ли компилироваться всякие извращенные шаблоны?

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

По моим наблюдениям, плюсовый код собирается вполне даже хорошо.
На фаталельные несовместимости со стандартом покамест не натыкался
ни разу (что, конечно же, не значит, что их нет:)).

Неявное инстанцирование умеет.
Частичную специализацию тоже вроде бы умеет.

Например:
pell@<hostname>:~/tmp/adsf> cat asdf.cpp
#include <iostream>

template<typename _T, size_t size>
inline size_t array_size( const _T(&)[size] ) { return  size ; }

template<typename _T, int cntr>
struct foo
{
        void print() const
        { std::cout << sizeof( _T ) << '\t' << cntr << std::endl ; }
} ;

template<typename _T>
struct foo3 : public foo<_T,3>
{
        void print() const
        { std::cout << sizeof( _T ) << "\tthree:)" << std::endl ; }
} ;

int main()
{
        const char      msg[] = "Hello, World!" ;
        std::cout << array_size( msg ) << std::endl ;

        foo<int,4>      asdf ;
        asdf.print() ;

        foo3<long>      qwer ;
        qwer.print() ;
}
pell@<hostname>:~/tmp/adsf> g++ -o asdf-gcc asdf.cpp
pell@<hostname>:~/tmp/adsf> icc -o asdf-icc asdf.cpp
asdf.cpp(21) : (col. 1) remark: main has been targeted for automatic cpu dispatch.
pell@bourov:~/tmp/adsf> ./asdf-gcc
14
4       4
4       three:)
pell@bourov:~/tmp/adsf> ./asdf-icc
14
4       4
4       three:)

pell
()

Зер гутт!

> ... компиляторы теперь поддерживают использование Intel Thread Building Blocks для автоматических оптимизаций...

Я правильно понимаю, что это тот же самый механизм, при помощи которого в ICC реализован OpenMP? А то что-то под вечер в голове уже каша сплошная:(

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

Совсем неправильно:(

Правильно здесь --- http://shareit.intel.com/WikiHome/Articles/111111288/Reference.pdf

Получается, что Intel Thread Building Blocks --- это что-то вроде хитрого расширения STL. Интересная, конечно, штука. Но уж больно сильно привязывает к Intel'овским решениям, ограничивая лицензионные возможности для разработки с использованием этой библиотеки.

2 all Интересно, а в boost есть что-нибудь похожее? Может кто-нибудь, хорошо знающий boost, ткнуть носом?

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

> А пример в, условно говоря, три строки можно показать?

Пример писать неохота :) Но это значит, что если вы используете шаблоны, то теперь необязательно включать непосредственный код в .h файлы (и таким образом показывать его), а можно спокойно писать в .cpp, как и обычно, только в каком-то месте надо приписать слово export (не помню где... то ли в .h то ли в .cpp).

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

:eek: нифига себе. Даже не представлял себе, что такое бывает.

Интересно, а как они компоновку обеспечивают такого чуда чудного?

Спасибо за информацию, буду посмотреть.

pell
()

Приятно послушать "экспертов".

Ага, давайте, излагайте.

anonymous
()

cavia_porcellus какое отношение "новость" имеет к

а) OpenSource, компилятор хоть и хороший но закрытый и код им генерированный на AMD не работает.

б) Linux

???

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

На ЛОРе даже пост про день рождения Куклачёва выльется в холивар. Однако я согласен, что даже Куклачёв имеет большее отношение к опенсорсу и линупсу чем пресловутый icc.

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

> на ней я поднял производительность hpl в 2.5 разаю

Ну это с чем сравнивать. У меня на процессоре с пиковой производительностью ~22 Gflops было так:
gcc4 + atlas: ~16 Gflops
icc9 + mkl: ~19 Gflops

Второй вариант определённо лучше первого, но не настолько, насколько дороже. :)

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

>А как ведет себя бинарник собранный icc на AMD?

В зависимости от опций использованных во время компиляции. Либо откатывается к неоптимизированному коду, либо вываливается с ошибкой.

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

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

Но видел статью каких-то българских студентов, которые сравнивали производительность ядер,скомпиленных gcc 3.2.3 и icc 8.1. Там упоминались некие патчи на ядро. Ядра брали вроде как 2.4 и раннее 2.6. Производительность получилась как обычно - то там, то там, но в целом icc показал лучше. Тестили на Р4...

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

> В зависимости от опций использованных во время компиляции. Либо откатывается к неоптимизированному коду, либо вываливается с ошибкой.

Видел статью где-то, что если в коде, сгенерированом icc, убрать проверку на тип процессора (это вроде довольно просто), то он прекрасно (с довольно неплохой производительностью в смысле) работает и на амд.

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

прекрасно работает если компилироть без оптимизации под конкректный проц

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