> А вот дядька Столлман не устает предупреждать о том, что на штырь в задницу вестись не стоит, даже если этот штырь гламурненький такой. И знаете, я с ним почему-то согласен. С чего бы это, а?

Потому что Вы тоже красноглазый и ведетесь на сомнительные красноглазые аналогии с вечно анальным подтекстом? Анальное рабство, штырь в задницу - все из этой оперы.

>А, да! Обещанные сцылки забыл. Держите:

Держите и Вы тогда: http://habrahabr.ru/blogs/linux/83324/

я бы не считала эти сравнения достоверными,

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

2-ая ссылка , во-первых они сравнивали ICC на AMD, во-вторых версия ICC очень старая, в-третьих The Benchmarking suite used was Perlbench 0.93 by Gisle Aas, утилита не очень точная, хотя я сама ей пользуюсь для сравнения, но обычно вкупе с результатами time

и еще момент, не нужно ICC называть полностью «проприетармым и недешевым», под достаточно большими ограничениями он бесплатен для некоммерческого использования на платформах Linux x86 и Linux x86_64

>Минусы
1. Неполная совместимость с gcc. Некоторые программы не собираются icc, некоторые собираются, но не работают. Например, программы, использующие алгоритм LZMA (xz-utils, p7zip), собираются, но не распаковывают архивы — мол, они битые. Уверен, что это не единственный пример.


если у кого есть регистрация на хабре - отпишите автору что это уже исправили, это стоило мне 2 месяцев переписки с Лассе Коллином ;)

>2. icc линкует исполняемые файлы с собственными библиотеками, и, если вы по каким-либо причинам решите удалить его, то вам придется пересобирать все пакеты, собранные им.


есть флаг -i-static

забыли главный минус - ограничения лицензии на использование выходящее за рамки некоммерческого

По поводу точности сравнения успорять не буду, - может вы и правы (читал я ваш обмен мнениями по поводу первой ссылки, очень интересно), а вот по поводу «проприетарный и недешевый» давайте разберемся.

Разве ICC стал открытым? Отнюдь. Или может ценник на ICC упал до нуля? Тоже нет. Так чем же вас смущает моя формулировка? Мне кажется она абсолютно точна.

Ведь говорить, что «под достаточно большими ограничениями он бесплатен для некоммерческого использования на платформах Linux x86 и Linux x86_64» это приблизительно тоже самое, что: «Да, вообще-то ICC кое-кому обходится недешево, но вот для Вас (только для Вас!) это будет дешевый компилятор. И вообще - первая доза (и тоже только для Вас!) - бесплатно.». Только говорится это другими словами!

вот мое (старое) сравнение ICC vs GCC с xz-utils

Tested with todays git snapshot,
#define restrict
#define lzma_restrict
this helps, xz and lzma compression and decompression worked okey, i was able to even perform PGO
on xz binary with ICC.

the permanent solution can be:

because of:

-icc The __ICC and __INTEL_COMPILER macros
are set to represent the current version
of the compiler.
Description:
This option determines whether certain Intel compiler
macros are defined or undefined.
If you specify -no-icc, the compiler undefines the __ICC
and __INTEL_COMPILER macros. These macros are defined by
default or by specifying -icc.

(taken from ICC manpage , this is true at least for ICC 10.1 and ICC 11.1, not sure about earlier 9.x 8.x 7.x versions,
but as i remember they do not try to mimic as GCC so agressively, while for 10.x and 11.x it is preffered behavior)


so unless user has specified -no-icc flag to compiler (which is unlikely)
__ICC and/or __INTEL_COMPILER macroses are defined, and if they are, then
#define restrict and #define lzma_restric so things work correctly.


Additionally:
Performance stats on (-xSSE2) profile guided optimized xz (using some piece of junk as data):
CPU: Core2 2Ghz

xz comp: 34.8 MiB / 45.5 MiB = 0.765 1.6 MiB/s 0:28
xz dec: 34.8 MiB / 45.5 MiB = 0.765 12 MiB/s 0:03
lzma comp: 34.8 MiB / 45.5 MiB = 0.765 1.6 MiB/s 0:28
lzma decomp: 34.8 MiB / 45.5 MiB = 0.765 12 MiB/s 0:03

same with GCC 4.1.2-27 (RedHat) compiled (no PGO, -O3 -fomit-frame-pointer -mfpmath=sse -msse2 -march=pentium-m):
xz comp: 34.8 MiB / 45.5 MiB = 0.765 1.6 MiB/s 0:29
xz decomp: 34.8 MiB / 45.5 MiB = 0.765 9.1 MiB/s 0:04
lzma comp: 34.8 MiB / 45.5 MiB = 0.765 1.6 MiB/s 0:29
lzma decomp: 34.8 MiB / 45.5 MiB = 0.765 9.1 MiB/s 0:04

conclusion: the results show not much difference between icc-pgo-optimized and gcc flags optimized versions,
but at least there are no regressions in speed,
possibly on large amounts of data this 3% speed boost can be more noticeable

691 Mb data decompression (linux kernel tree with object files) (lzma):
GCC: 691.25 MB in 00h00m13.28s: 52.04 MB/second
ICC: 691.25 MB in 00h00m11.53s: 59.95 MB/second

XZ decompression of slackware 13.0 qt package (xz):
GCC: 100.07 MB in 00h00m05.91s: 16.90 MB/second
ICC: 100.07 MB in 00h00m05.02s: 19.92 MB/second

conclusion: xz and lzma decompression worked, there is noticeable speed difference even )

>Некоторые программы не собираются icc, некоторые собираются, но не работают.

Так и есть. Сам пытался собрать как-то генту с помощью ICC - это было печальное зрелище - масса ошибок. Правда я так детально их не анализировал.

>Мне кажется она абсолютно точна.

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

Можно конечно до позеленения доказывать что ICC лучше чем GCC , но

1) он собирает не все, а даже если собирает, то это может работать некорректно, причем баги вылезают достаточно неожиданные, GIMP у меня например открывал все JPEG (или PNG? не помню уже) как прозрачный фон,
про сломаную (теперь уже починенную!) декомпрессию в xz уже упомянули на том хабре, для Лассе Коллина это было несколько неожидано, т.к. с GCC было все в порядке, в Arora журнал последних посещений превращается в кучу мусора....

2) бесплатный ICC недоступен для дистростроителей и пакетосборщиков

3) есть нарекания на производительность кода в случае использования не-Intel процессоров

этого вообщем-то достаточно чтобы GCC вышел победителем в сравнении,
ну и разница в 13-15% на самом деле ощутима только для задач интенсивно использующих процессор, тут скорее нужно стремиться к оптимизации алгоритма в самих программах, в случае multimedia задач, тут очень много было переписано на ассемблер (и поэтому сравнения GCC vs ICC на multimedia задачах достаточно некорректны!).

я собираю ffmpeg, компрессоры , одно время собирала xorg-server 1.4.x пока он не излечился от жадности в поедании процессора, libjpeg, libpng, zlib, libbz2, во всем остальном - GCC, причем скорее 4.3.x чем 4.4.x , иногда даже 4.1-redhat (например сабжевый Clang у меня только им и собрался)

mplayer с ICC ведет себя достаточно глючно в последнее время, хотя в целом может показаться что он нормально работает, но может например не играть видео с сети...

[вброс] clang как фронтэнд для ... GCC

программа Hello World на C
собираю

$clang -v hello.c -o /tmp/hello
clang version 1.1 (trunk 95490)
....
«/home/sylvia/bin/gcc» -v -c -m32 -o /tmp/cc-o6lY15.o -x assembler /tmp/cc-0VZKke.s
Using built-in specs.
gcc version 4.3.4 /argenta/
as --gdwarf2 -V -Qy -o /tmp/cc-o6lY15.o /tmp/cc-0VZKke.s
GNU assembler version 2.20
...
«/home/sylvia/bin/gcc» -v -m32 -o /tmp/hello /tmp/cc-o6lY15.o
...
/usr/i586-sylvia-linux/libexec/gcc/i586-sylvia-linux/4.3.4/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o /tmp/hello /usr/lib/crt1.o /usr/lib/crti.o /usr/i586-sylvia-linux/lib/gcc/i586-sylvia-linux/4.3.4/crtbegin.o -L/usr/i586-sylvia-linux/lib/gcc/i586-sylvia-linux/4.3.4 -L/usr/i586-sylvia-linux/lib/gcc/i586-sylvia-linux/4.3.4/../../.. /tmp/cc-o6lY15.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/i586-sylvia-linux/lib/gcc/i586-sylvia-linux/4.3.4/crtend.o /usr/lib/crtn.o


Получается что Clang тут всего лишь поработал препроцессором... все остальное же сделали за него GCC и gas. Спрашивается почему Clang не может сам довести дело до конца ? Смешно же...

> С такого, что GCC - неповоротливый монстр, в который всё труднее и труднее вносить изменения. LLVM намного проще в поддержке.

Только вот дело в том, что gcc - работает. В природе все еще нет другого компилятора, которым можно бы было собрать всю систему, даже эти ваши bsd.

> Получается что Clang тут всего лишь поработал препроцессором... все остальное же сделали за него GCC и gas

Тут Clang сгенерировал асемблерный код, который передал GCC, так что «всего остального» не так уж много.

так почему он не хочет использовать

$llvm-as --version
Low Level Virtual Machine (http://llvm.org/):
llvm version 2.7svn
Optimized build with assertions.

$llvm-ld --version
Low Level Virtual Machine (http://llvm.org/):
llvm version 2.7svn
Optimized build with assertions.

а вызывает gcc , gas и gcc в качестве линкера?

тот же упомянутый ICC может использовать GCC лишь только для обработки #pragma и некоторых GCCизмов, а также libstdc++ , но ассемблерный код и компоновку он делает сам


.... какой-то неполноценный этот Clang вообщем...


кстати насчет сроков разработки
$icc --version
icc (ICC) 11.1 20090827
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

1985

> так почему он не хочет использовать

$llvm-as --version

$llvm-ld --version

а вызывает gcc , gas и gcc в качестве линкера?

Насколько я понимаю, llvm-{ld,as} работают с файлами ассемблером и кодом самой LL VM, а llvm-gcc выдает ассемблер i386.

.... какой-то неполноценный этот Clang вообщем...

Он универсальный - может и так, и этак :)

ps:

$clang -v -emit-llvm -S hello.c -o /tmp/hello.S
$llvm-as hello.S -o hello.o
$llvm-ld hello.o -o hello
$./hello
hello


а ведь может, но не хочет...

pps: это все к тому что те , кто поднимают слишком много шума о GCC-free системе, должны вначале заставить

1) Clang не использовать GCC по умолчанию, а полагаться на llvm (хотя может это и моя вина в том что не нашла явных опций для отключения GCC, и не стала рыться в дебрях документации чтобы найти что и как, да , мне было лень смотреть дальше GettingStarted и ./configure --help )
2) подумать о замене libstdc++

А сравнительных тестов msvc и gcc (mingw к примеру) никто не знает?

>Мне могут возразить насчет других процессоров, поэтому я сразу отвечу - «не нужны».

ARM. Читал оценки, что нетбуки на основе ARM при поддержке Google могут выкинуть архитектуру i386 из сегмента нетбуков к 2011-му году.

И не забываем про различные приятные смартфоны. Глядишь, после iPad'а там же возникнут более другие устройства с большим функционалом.

Сам посмотрел, пара из верхних ссылок гугля

http://keyj.s2000.ws/?p=86 http://bvector.blogspot.com/2009/08/compilers-test-icc-vs-msvc-vs-gcc.html

И ктот там пердел про отличную оптимизацию в msvc ? Нечего особенного, даже хуже чем в gcc

>И что? Это опциональное, а не обязательное условие. Очистите ядро от всех легаси костылей, которые мешают его собрать другими компиляторами. Ядро FreeBSD, кстати, уже давно можно собрать icc.

Чтобы линукс влачил такое же жалкое существование, как фряха, которую MS не рассматривают как конкурента, кстати? Ну уж нет.

Там все хитро. GCC он использует как пускалку для gas. Причины этого туманны и нелепы, что-то с default entry point связанное.

У него же свой llvm-as есть!

llvm хорошо независимо от BSD или GPL

>а что такое Visual Studio?

))))))))+1

llvm-as компилирует llvm в биткод. А llc компилирует биткод в нейтив, и для этого он дергает gcc вместо gas.

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

Бондарчук, перелогинтесь!

>Вот именно. Бздуны постоянно поливают грязью GNU, но ничего не могли поделать - они без GNU жить не могли, так как полноценной ОС без окружения GNU у них не было.

Теперь Apple им предложила приотовить, образно говоря, еду.

Да, Apple очень беспокоится о здоровье троллей. Покушай и ты.

После пригтовления Apple всё сожрёт, а объедки и крошки бздунам отдаст, чтобы раньше времени не сдохли - кто-то же должен в рабстве быть.

Ты думаешь, что бздуны пишут код за еду? Не, среди них вроде не так много индусов.

>Да да, эти люди перелазят на новую версию windows и просят маму купить не только планку памяти, а ещё много планок памяти, и видюху с процессором, и жёсткий диск побольше.

И ещё целую бочку варенья да целую корзину печенья.

>>случившееся с MySQL должно послужить уроком

О да, пагни шли к успеху, нехило подняли бабла со сделки, а потом стали вопить «Спасите наш проект!». И каким-то идиотам даже не лень было распространять этот призыв.

+1

>Но касательно шрифтов: определите, пожалуйста, Ш не Г. Поскольку я под этим понимаю нечто вроде того, что есть в XP, т.е. отключенное сглаживание и антиалиазинг только на больших размерах. В OS X, насколько я знаю, это настраивается в лёгкую.

В OS X, насколько я знаю, это настраивается в лёгкую.

насколько я знаю

Дак ты ещё и OS X в глаза не видел?

>In what language is LLVM written?

All of the LLVM tools and libraries are written in C++ with extensive use of the STL.

Очень сильно сомневаюсь в нужности этой быдлокодерской поделки.

>> gcc твой умеет свой parse tree в XML выдать?

Судя по существованию gccxml, это можно сделать

можно, но результат ты не сможешь использовать как хочешь — GNU FSF (емнип) наложило запреты на ряд случаев использования

вот так