Пока имеется только компилятор по винду.

>Currently, you will be able to download Intel® C++ Compiler 8.1 for Linux*.

>Intel® C++ Compiler 9.0 for Linux* will be made available in August, 2005.

У icc есть некоторая не очень неприятная тонкость ...
В винде он подражает компилю MS, в linux gcc,
в итоге он сам с собой несовместим в разных осях.
В частности эти самые ключи gcc он понимает только в версии для 
linux.

Учимя читать:

In order to understand the needs of our Non Commercial customers better 
and give more exposure to our Non Commercial offering, we are making 
some adjustments to this program. Until August 2005, our Non Commercial 
customers will continue to get Intel® Compilers version 8.1. After that, 
they will be able to access and download our latest Intel Compilers 
version 9.0.

А купить или триалку попросить можно прямо сейчас.

Проприетарщину на свалку !
У меня в нём надобности никогда не возникало :)
процессора либо AMD либо IBM :)

А гже версия для яблочников ?? :)

зачем для яблочников если они на платформу Intel переходят? :)

http://www.stlport.com/dcforum/DCForumID5/1013.html http://www.stlport.com/dcforum/DCForumID7/2351.html#3

>зачем для яблочников если они на платформу Intel переходят? :)

А компилятор под MacOSX x86 не нужен?

>Проприетарщину на свалку !
Однозначно ! gcc рулит, а новая доточенная четвертая ветка будет вообще заруливать !

icc кто-нибудь мозиллу собирал? Если да, то с каким результатом по сравнению с gcc -O2 ?

"Однозначно ! gcc рулит, а новая доточенная четвертая ветка будет вообще заруливать !"

Если вообще заведётся и будет код делать хоть как-нибудь.

Не мозилку, но собирал процентов 10-15 быстрее чем -03 У них в 8 компилере CDT была еще 1.x - не совсем рулез, а вот если там вторая CDT это хорошо, надо будет посмотреть насколько это удобнее посравнению с ECB. Но ECB всеравно рулез.

Zlobec.

>icc кто-нибудь мозиллу собирал?

По моему, он не настолько совместим с gcc, чтобы им можно было бы собрать большой проект. Во всяком случае, ни ядро ни MPlayer им точно без кучи костылей не соберешь. Во всяком случае, так было когда у меня домашний комп был 266МГц, и для меня это было актуально.

Вообще-то мозилла, должна поменьше спецфич gcc использовать, так что может быть. Но мозилла и не требует каких-то там серьезных вычислений, так что вряд ли заметишь видимый прирост производительности. imho мозилла - это постоянный *alloc/dealloc, а они от компилятора не сильно зависят.

>anonymous (*) (16.06.2005 13:22:09):Если вообще заведётся и будет код делать хоть как-нибудь.

http://www.linux.org.ru/jump-message.jsp?msgid=950450&lastmod=1118914623955

Тоесть он как бы завелся и даже сделал код "хоть как-нибудь". Сюрприз. Я честно скажу еще не щупал, но пока никто не кричал что не работает. Так что..

> 2 robot12 (*) (16.06.2005 12:03:28)

Аналогично... IBM S/390 + 2 & 4 - процессорные Opteron-ы ( в качестве рабочих станций ). Думаю, нам тож - не слишком актуально... ;-)

>icc кто-нибудь мозиллу собирал?

Собирали, и успешно. Результатов в части производительности не знаю.

> А компилятор под MacOSX x86 не нужен?

Apple пользует gcc

А зачем оно вообще это нужно? "Автору С++ место в дурке или на погосте" (с) В.С.Луговский. Кто это пишет прикладные задачи на C++? Фортран-90 для русских физиков, выбирающих Slackware, еще пригодится ротор дивергенции считать (==0):)), а это зачем?

В сад

>Вообще-то мозилла, должна поменьше спецфич gcc использовать, так что может быть. Но мозилла и не требует каких-то там серьезных
>вычислений, так что вряд ли заметишь видимый прирост производительности. imho мозилла - это постоянный *alloc/dealloc, а они от компилятора не сильно зависят

На P150 разница между gcc -O2 и -O3 для мозиллы ощутима.

>У icc есть некоторая не очень неприятная тонкость ... >В винде он подражает компилю MS, в linux gcc, >в итоге он сам с собой несовместим в разных осях. >В частности эти самые ключи gcc он понимает только в версии для >linux.

однако вы извращенец! :)

Мне интересно а как приделать то к Eclipse какой-либо C комплиятор?

>Мне интересно а как приделать то к Eclipse какой-либо C комплиятор?

http://www.eclipse.org/cdt

>Кто это пишет прикладные задачи на C++?

К сведению любителей Фортрана, большинство современных CFD программ написано на плюсах.

>ротор дивергенции

Может наоборот?

>>Кто это пишет прикладные задачи на C++? >К сведению любителей Фортрана, большинство современных CFD программ написано на плюсах.

И шо? Мне теперь резко бросаться переписывать весь мой код на С++? А нафига собственно?

>И шо? Мне теперь резко бросаться переписывать весь мой код на С++? А нафига собственно?

Тебя кто-нибудь заставляет что-ли? Пишешь на фортране и пиши. Вопрос то был:

>>Кто это пишет прикладные задачи на C++?

Ну вот я пишу прикладные программы на С++ :) И никого не призываю следовать моему примеру. И многие сиэфдишники пишут ;)

> К сведению любителей Фортрана, большинство современных CFD программ написано на плюсах.

И что с того? Ниши разные.

"большинство современных CFD программ" - это мейнстрим, инженерные расчёты...

Фортран - исследователям... DNS турбулентного потока с приличным числом Рейнольдса, к примеру, ни одна из "большинства современных CFD программ" не осилит.

>И что с того? Ниши разные.

В каком месте они разные ?

>"большинство современных CFD программ" - это мейнстрим, инженерные расчёты...

>Фортран - исследователям... DNS турбулентного потока с приличным числом Рейнольдса, к примеру, ни одна из "большинства современных CFD программ" не осилит.

Это вы мух с котлетами путаете ;)

Скажу по секрету - на плюсах проще кодировать именно сложные вещи. Ту задачу, которую фортранист решает месяц я решу на плюсах за неделю.

Группа академика Захарова, из института Ландау, считает турбулентность именно на плюсах, а не на фортране. Это к вопросу о том, что выбирают исследователи.

>А зачем оно вообще это нужно? "Автору С++ место в дурке или на >погосте" (с) В.С.Луговский. Кто это пишет прикладные задачи на C++? >Фортран-90 для русских физиков, выбирающих Slackware, еще пригодится >ротор дивергенции считать (==0):)), а это зачем?

начнем holy wars?

Ну.... вот недавно звонит мне друг. В их институте некто написал прогу, вычисляющую собственные значения какого-то оператора, причем значения эти варьируются от 1E+15 до 1E-30, причем важно точно посчитать все, а прогу писали на дельфях, и как следствие -- задача считается криво! а вот в C++ такой проблемы не возникло бы принципиально -- там есть ШАБЛОНЫ! гипер удобная вещь, которую оценил только когда MTL начал юзать (matrix template library)

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

> Фортран - исследователям... DNS турбулентного потока с приличным числом Рейнольдса, к примеру, ни одна из "большинства современных CFD программ" не осилит.

Большинство коммерческих программ - действительно, как правило RANS или LES, программ для DNS мне не попадалось. Я занимаюсь чисто исследовательскими задачами, в частности расчетами 3-D нестационарных течений с хим. кинетикой, исп. уравнения NS. Программа собственная, в смысле, разработана нашей группой. Сначала использовали Фортран, потом переписали на плюсах. По-моему, плюсы достаточно удобны и для сложных задач. Но никого в свой лагерь не зову, пусть все используют то, к чему привыкли!

2 sS:

> Скажу по секрету - на плюсах проще кодировать именно сложные вещи. Ту задачу, которую фортранист решает месяц я решу на плюсах за неделю.

При всём уважении, тут вы не правы. В той области, про которую я говорю (DNS турбулентных течений) сложность отнюдь не в коде, а в схемах и алгоритмах. Собственно написание кода - это процентов 5 от общего времени , плюс отладка ещё процентов 15.

> Группа академика Захарова, из института Ландау, считает турбулентность именно на плюсах, а не на фортране.

Любопытно, что они там такое считают... Спецов по прямым расчётам турбулентности (DNS) в России по пальцам одной руки сосчитать.

Навскидку: http://xxx.arxiv.cornell.edu/find/physics/1/au:+Zakharov_V/0/1/0/all/0/1

> В той области, про которую я говорю (DNS турбулентных течений) сложность отнюдь не в коде, а в схемах и алгоритмах

Как раз на плюсах удобнее формализовывать алгоритмы. Я говорил не о времени счёта а о цикле реализации.

BTW: DNS это тупо размер сетки (чем от толше тем лучше) а это как раз проще реализовать именно на плюсах. У фортрана возможности работы в распеределённоё среде сильно меньше чем у плюсов. Их там собственно два с половиной.

Про DNS vs RANS/LES в комерческих пакетах.

Там DNS особо не нужен так как в промышленности достаточно точности Рейнольдсовских приближений по самое немогу.

Практикам тупо начхать на всякие масштабы турбулентности, еЯ анизотропию и прочий бред. Они мыслят совсем в других категориях ;)

Вдогонку

Не знаю как насчёт проприетарных пакетов (давно их не смотрел) а тот же самый OpenFOAM всесь из себя такой плюсовый умеет DNS на ура.

Какая разница? Всё равно нуль. Главное, что на "плюсах". Которые тормозят (на SciMark) нипадеццки даже по сравнению с Жабой от ИБМ.

http://www.shudo.net/jit/perf/SciMark-P4.png

>Главное, что на "плюсах". Которые тормозят (на SciMark) нипадеццки даже по сравнению с Жабой от ИБМ.

Я сравнивал время счета на двух версий одной программы на фортране и C++ (одна и та же 3-D сетка в 3375000 ячеек, используется RANS, k-e модель турбулентности, кинетика Моретти). Время счета практически одинаково (время расчета программы на плюсах на ~3% меньше). Да, компилятор g++/g77.