Компилятор Intel C/C++ в действии

[kolyan]

Друзья, а кто что может сказать о компиляторе Intel C/C++, в частносте, последней версии 8.х? Имеет ли смысл использовать его вместо GCC?

В пресс-релизах по выходу 8.х утверждается, что компилятор на 100% совместим с GCC на уровне исходных текстов и бинарных файлов. Так ли это?

В любом случае, все тесты производительности кода, скомпилированного с помощью GCC и ICC, говорят в пользу последнего. Для некоторых мультимедийных приложений достигается 25%-ое увеличение производительности! И лично у меня нет оснований не верить этому.

Я являюсь пользователем FreeBSD, поэтому инетресен также вопрос совместимости ICC с этой ОС. Насколько я понял, из портов компилятор собирается в режиме совместимости с Linux. Насколько это ухудшает общую картину? И можно ли собрать "родную" версию компилятора на фре?

[alv]

по поводу предыдущей версии компилятора было большое исследование на iXBT (на примере Suse, если память не изменяет).

[Cap. J2A]

Для каких целей планируется использовать icc?

[kolyan]

Для каких целей планируется использовать icc?

↑

Пока интересуюсь только для личного использования в экспериментальных целях. На десктопной платформе. Сборка приложений, в идеале - ядра. Особенно "тяжелых" приложений вроде mplayer, kde, amarok, mesa, xorg и т.д. Нацеленность, конечно, на использование ICC в связке с FreeBSD.

Вообще хотелось бы проверить потенциал ICC в плане сборки приложений, затем распространения бинарных пакетов.

Вторая по важности задача - проверить потенциал ICC для сборки серверных приложений, в частности, СУБД. Здесь любой прирост производительности будет не лишним.

to alv:
Запрос на гугль типа "site:ixbt.com компиляторы" дал кучу ссылок, в т.ч. относящихся и к интеловскому компилеру. Но, к сожалению, тексты статей больше количественного характера, чем качественного. Это, в основном, тесты производительности.

[polachok]

Вообще хотелось бы проверить потенциал ICC в плане сборки приложений, затем распространения бинарных пакетов.

хотите так проверяйте - потом нам расскажете

[Cap. J2A]

Пока интересуюсь только для личного использования в экспериментальных целях. На десктопной платформе. Сборка приложений, в идеале - ядра. Особенно "тяжелых" приложений вроде mplayer, kde, amarok, mesa, xorg и т.д. Нацеленность, конечно, на использование ICC в связке с FreeBSD.

Уууу. Я надеялся на то. что в качестве "тяжелых" будут программы, считающие днями-неделями-месяцами, а тут десктопные приложения, которые бОльшую часть времени ожидают реакции пользователя. IMHO, в этом плане выгоднее использовать gcc как более проверенный инструмент.

Вторая по важности задача - проверить потенциал ICC для сборки серверных приложений, в частности, СУБД. Здесь любой прирост производительности будет не лишним.

↑

Не согласен. У СУБД критичная часть -- дисковая подсистема. Тем более, сборка непроверенным компилятором может привести к малопредсказуемым последствиям.


Anyway, удачи.

[Данил]

Я хотел скачать , но почти 200 мб ОТПУГНУЛИ
Он бесплатен для некоммерческого использования!
Буду ждать на каком нибудь диске
gcc4.0.1 не инсталлится (too many errors)

[elide]

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

я только не понял, в чем проблема? что мешает попробовать, а потом нахреначить статью по этому делу и заиметь большой респект от сообщества?

[vorphalack]

Вообще хотелось бы проверить потенциал ICC в плане сборки приложений, затем распространения бинарных пакетов.

↑

ports/lang/icc

ports/lang/icc7

и нефиг тута выпендриваться...

[alv]

что мешает попробовать, а потом нахреначить статью по этому делу и заиметь большой респект от сообщества?

↑

золотые слова, однако

[Cap. J2A]

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

↑

Откуда такие ощущения? Можно вообще ничего не получить.
На Линуксе, на web-сервере при 60 дней аптайма, любой из kernel-процессов не набирает более 40 секунд процессороного времени.

[elide]

На Линуксе, на web-сервере при 60 дней аптайма, любой из kernel-процессов не набирает более 40 секунд процессороного времени.

просто когда, например, веб-сервер читает страницу с диска, то работает ядро (драйвера ATA, драйвера файловой системы, затраты на обработку всяких там fopen, fread, fclose...) но процессорное время идет на счет веб-сервера.
если пересобрать ядро с оптимизацией - у тебя сам веб-сервер будет работать быстрее, а не только процессы ядра.

[Cap. J2A]

Для elide: неубедительно. В IO запросах, AFAIK, узкое место жесткий диск, а не ядро. Приведи первоисточник.

[elide]

а почему I/O запросы - это жесткий диск? это еще и сеть (:
мысли глобальнее. первоисточник - здравый смысл.

[Cap. J2A]

Для elide: если бы ты входил в kernel team любого дистрибутива, или бы процитировал одного из, то в этом случае вполне можно было доверится твоему здравому смыслу. Иначе это просто слова, ничем не подкрепленные.

[elide]

Для Cap. J2A: если бы ты был Посланником Небес на земле, то в этом случае меня бы волновало, веришь ты мне или нет. иначе, мне похрену....

[Alagert]

Подеоюсь с вами реальным опытом: ща я занимаюсь доделыванием своей либы для БПФ в конечных полях. Собирал оную и gcc и icc. На интеловских процах, последний дает порядка 20-25% прироста производительности. Но на АМД процах такого не замечено
А вообще у меня знакомый пересобрал gentoo с использыванием icc. Все собралось и заработало. Проги реально работают быстрее. Субъективно на 15-20%.

[ddc]

Для Cap. J2A:
Любые задержки при работе с железом имеют две компоненты: аппаратную (характер реакции железа) и программную (характер опросов железа). Что касается подсистемы памяти, то опросы жёсткого диска дают пренебрежимо малое запаздывание в сравнении с его ответами; тако же и в устройствах UI. А вот в подсистеме оперативной памяти и сети всё строго наоборот, так что средняя температура по больнице при пересборке ядра всё равно изменится. Вопрос в том, какой нам нужен больной.

[Cap. J2A]

Есть ли хоть одно физическое подтверждение или хотя бы заявление авторитетного в вопросах ядра человека (а именно на это я намекал когда говорил о kernel team) по этому (заметим ли мы хоть какое-то увеличение производительности при пересборке ядра icc) вопросу? Иначе это просто слова, ничем и никем не подтвержденные.

[kolyan]

Есть ли хоть одно физическое подтверждение или хотя бы заявление авторитетного в вопросах ядра человека (а именно на это я намекал когда говорил о kernel team) по этому (заметим ли мы хоть какое-то увеличение производительности при пересборке ядра icc) вопросу? Иначе это просто слова, ничем и никем не подтвержденные.

↑

Cap. J2A, вы как минимум не адекватно себя ведете.

1. Вам, чтобе доказать 2+2=4 тоже академик РАН нужен? Конечно, вещи о которых говорил ddc не столь очевидные, но они общеизвестные, по крайней мере в сообществе юниксоидов.

2. Если вы не заметили, на этом форуме почти все бездоказательно приводится, основываясь на личных умозаключениях предпочтительно неспециалистов, а также на аналогичных выводах в открытых тематических ресурсах сети интернет. Если вам так необходимы мнения компитентных в обсуждаемых областях людей, то непонятно, зачем вы вообще начали писать в этой ветке. Приглашаю вас посетить kernel.org, freebsd.org, и т.д. - там вы можете услышать мнения профессионалов.

Дальнейшее обсуждение этой темы считаю бессмысленным. Если есть кому-то что сказать по делу, говорите. А споры не по существу и базарные толки давайте не будем больше разводить.

[Cap. J2A]

kolyan: с нетерпением жду результатов Вашего эксперимента. Единственная просьба -- кол-во измерений не менее 3-х.

P.S. Несмотря на общеизвестные рекомендации по пересборке ядра для увеличения производительности, файты показывают, что в случае "тяжелых" задач научного характера, разницы практически нет: http://wiki.atmsk.ru/index.html/GCCForScience

[Cap. J2A]

На Линуксе, на web-сервере при 60 дней аптайма, любой из kernel-процессов не набирает более 40 секунд процессороного времени.

просто когда, например, веб-сервер читает страницу с диска, то работает ядро (драйвера ATA, драйвера файловой системы, затраты на обработку всяких там fopen, fread, fclose...) но процессорное время идет на счет веб-сервера.

Есть предложение, как посчитать cputime у апача за месяц?
Потому как:

Код: Выделить всё

 yurevich@c3r111:~$ uptime
   14:25:43 up 63 days, 23:50,  1 user,  load average: 0.00, 0.00, 0.00
  yurevich@c3r111:~$ ps aux
 USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
 root         1  0.0  0.1  1272  484 ?        S    Jul18   0:04 init [2]
 root         2  0.0  0.0     0    0 ?        SW   Jul18   0:00 [keventd]
 root         3  0.0  0.0     0    0 ?        SW   Jul18   0:00 [kapmd]
 root         4  0.0  0.0     0    0 ?        SWN  Jul18   0:00 [ksoftirqd_CPU0]
 root         5  0.0  0.0     0    0 ?        SW   Jul18   0:23 [kswapd]
 root         6  0.0  0.0     0    0 ?        SW   Jul18   0:00 [bdflush]
 root         7  0.0  0.0     0    0 ?        SW   Jul18   0:05 [kupdated]
 root         8  0.0  0.0     0    0 ?        SW   Jul18   0:00 [xfsbufd]
 root         9  0.0  0.0     0    0 ?        SW   Jul18   0:03 [xfslogd/0]
 root        10  0.0  0.0     0    0 ?        SW   Jul18   0:00 [xfsdatad/0]
 root        11  0.0  0.0     0    0 ?        SW   Jul18   0:00 [khubd]
 root        73  0.0  0.0     0    0 ?        SW   Jul18   0:00 [xfssyncd]
 root        74  0.0  0.0     0    0 ?        SW   Jul18   0:00 [xfssyncd]
 root        75  0.0  0.0     0    0 ?        SW   Jul18   0:00 [xfssyncd]
 root        76  0.0  0.0     0    0 ?        SW   Jul18   0:00 [xfssyncd]
 root        77  0.0  0.0     0    0 ?        SW   Jul18   0:00 [xfssyncd]
 root       222  0.0  0.2  1344  592 ?        S    Jul18   0:16 /sbin/syslogd
 root       225  0.0  0.1  1264  448 ?        S    Jul18   0:00 /sbin/klogd
 spam       231  0.0  9.3 25608 23892 ?       S    Jul18   0:01 /usr/sbin/spamd --create-prefs --max-children 5 --helper-home-dir --username=spam --syslog=mail
 clamav     286  0.0  0.3  7732  800 ?        S    Jul18   0:00 /usr/sbin/clamsmtpd
 root       290  0.0  0.2  1484  656 ?        S    Jul18   0:00 /usr/sbin/dhcpd-2.2.x -q eth1
 root       295  0.0  0.1  1292  504 ?        S    Jul18   0:00 /usr/sbin/inetd
 root       299  0.0  0.2  1420  652 ?        S    Jul18   4:44 /usr/sbin/nacctd
 root       302  0.0  0.1  1608  496 ?        S    Jul18   0:00 /usr/sbin/popa3d -D
 root       391  0.0  0.3  2464 1000 ?        S    Jul18   0:17 /usr/lib/postfix/master
 postfix    394  0.0  0.4  2620 1192 ?        S    Jul18   0:57 qmgr -l -t fifo -u -c
 root       397  0.0  0.3  2704  924 ?        S    Jul18   0:00 /usr/sbin/nmbd -D
 root       399  0.0  0.4  3576 1052 ?        S    Jul18   0:00 /usr/sbin/smbd -D
 daemon     408  0.0  0.2  1384  556 ?        S    Jul18   0:00 /usr/sbin/atd
 root       411  0.0  0.2  1652  660 ?        S    Jul18   0:00 /usr/sbin/cron
 root       436  0.0  0.1  1252  468 tty5     S    Jul18   0:00 /sbin/getty 38400 tty5
 root       437  0.0  0.1  1252  468 tty6     S    Jul18   0:00 /sbin/getty 38400 tty6
 clamav     464  0.0  0.3  7732  800 ?        S    Jul18   0:00 /usr/sbin/clamsmtpd
 clamav    9727  0.0  0.4  2344 1140 ?        S    Jul27   0:02 /usr/bin/freshclam -d --quiet -p /var/run/clamav/freshclam.pid
 clamav    9913  0.0  6.4 18272 16564 ?       S    Jul27   1:47 /usr/sbin/clamd
 clamav    9953  0.0  6.4 18272 16564 ?       S    Jul27   0:00 /usr/sbin/clamd
 root     30279  0.0  0.0     0    0 ?        SW   Aug09   0:00 [usb-storage-0]
 root     30280  0.0  0.0     0    0 ?        SW   Aug09   0:00 [scsi_eh_0]
 fetchma  32510  0.0  1.2  4380 3160 ?        S    Aug09   0:25 /usr/bin/fetchmail --daemon 300 --syslog -f /etc/fetchmailrc -i /var/mail/.fetchmail-UIDL-cache
 root     32640  0.0  0.1  1252  468 tty3     S    Aug09   0:00 /sbin/getty 38400 tty3
 root     32647  0.0  0.1  1252  468 tty2     S    Aug09   0:00 /sbin/getty 38400 tty2
 root     32649  0.0  0.1  1252  468 tty4     S    Aug09   0:00 /sbin/getty 38400 tty4
 root     18026  0.0  0.3  2784  856 ?        S    Aug10   0:00 /usr/sbin/sshd
 root     24969  0.0  0.1  1252  468 tty1     S    Sep08   0:00 /sbin/getty 38400 tty1
 spam     27039  0.0 12.1 32592 30940 ?       S    Sep15   0:31 spamd child
 spam      2628  0.0 11.9 32164 30472 ?       S    Sep15   0:30 spamd child
 spam      3629  0.0 11.0 29856 28164 ?       S    Sep15   0:26 spamd child
 spam      4865  0.0 11.9 32164 30536 ?       S    Sep16   0:28 spamd child
 spam      6747  0.0 11.1 30044 28356 ?       S    Sep16   0:28 spamd child
 root      6046  0.0  0.5  2972 1448 ?        S    Sep19   0:00 /usr/sbin/apache
 www-data 17728  0.0  0.6  3064 1648 ?        S    00:05   0:00 /usr/sbin/apache
 www-data 18182  0.0  0.6  3056 1644 ?        S    00:34   0:00 /usr/sbin/apache
 www-data 28585  0.0  0.6  3056 1640 ?        S    13:29   0:00 /usr/sbin/apache
 www-data 28645  0.0  0.6  3052 1640 ?        S    13:30   0:00 /usr/sbin/apache
 www-data 28648  0.0  0.6  3060 1648 ?        S    13:33   0:00 /usr/sbin/apache
 www-data 28649  0.0  0.6  3056 1628 ?        S    13:33   0:00 /usr/sbin/apache
 www-data 28846  0.0  0.6  3052 1628 ?        S    13:47   0:00 /usr/sbin/apache
 www-data 28847  0.0  0.6  3056 1596 ?        S    13:47   0:00 /usr/sbin/apache
 postfix  29058  0.0  0.3  2436 1000 ?        S    14:00   0:00 pickup -l -t fifo -u -c
 root     29193  0.0  0.5  5704 1512 ?        S    14:13   0:00 /usr/sbin/sshd
 yurevich 29195  0.0  0.6  5796 1640 ?        S    14:13   0:00 /usr/sbin/sshd
  yurevich 29196  0.0  0.6  2696 1604 pts/0    S    14:13   0:00 -bash
 yurevich 29434  0.0  0.3  2564  768 pts/0    R    14:27   0:00 ps aux