[loroogle] icc

а то )

аргументы будут?
или так и будешь сотрясать воздух^Wзахламлять базу?

>Проприетарщина? :(

Х.З: http://www.calculate-linux.ru/packages/licenses/Intel-SDP

вот поэтому и стрёмно :)

Значит, это не для меня. А нет ли смысла clang попробовать, или там дела ещё хуже?

как подсказывают профитов нет (можно так сказать)

Как-то я прикручивал к portage, сделав некий use-флаг icc (конфиги потерял уж). Перекомпиляция pango дала неплохой эффект =) Но надоели глюки, вернул все на gcc

Я его пробовал в треде про тормозный Линукс, собирал p7zip. Результат очень даже неплохой оказался, полученный бинарник по сути догнал по скорости вендовый.

ну у тебя вроде как 64?
на 32 с 72-м не хочет

Да, 32 битку я не пробовал, но 64 собралась на ура. Кстати, компилит он тоже быстрее чем gcc

собирает он быстрей, это да
но, по крайней мере, в 32-х битном варианте капризный

а вот с питоном хорошо - емерж стал на ~10% шустрее считать зависимости :)

У p7zip между:
-march=native -Ofast -pipe -g0 -s -Wno-all --param l2-cache-size=256
(такой вариант с L2 оказался самым быстрым на i5, по дефолту там было 3 метра, что по ряду причин абсолютно неправильно)

-xSSE4.2 -O3 -fp-model fast=2 -g0 -fpermissive

разница в пределах погрешности. +- секунда в тестах и +- десяток mips в бенчмарке.

но таки поломало layman и emerge_после_синка )

>-Ofast
о_О wtf?

>о_О wtf?

ты ж знаешь, что у меня gcc 4.6.0)
Пока Ofast = O3 + ffast-math

>ты ж знаешь, что у меня gcc 4.6.0)
точно ^_^

а что за версии icc и p7zip?
оно и с твоими флагами не собирается
точнее не работает )

[I] dev-lang/icc (11.1.072@09/01/10): Intel compiler suite for Linux
[I] app-arch/p7zip (9.13@09/01/10): Port of 7-Zip archiver for Unix

аналогично
так почему не работает?
64?

да, 64 битный

P.S. sqlite слегка замедлился, python никакой разницы не показал.

ааа - вот в том то и дело :)
на 32 уже не айс

на скуле разницы не ощутил
питон шустрей получился, но собака багов потом показывал кучку (

bzip2 - ускорение ~10%

а всё от чего?
от того что гцц гораздо прилежней пилят именно для 64 - и векторизации и графиты всякие и прочее-прочее-прочее в 64 гораздо вкуснее

не просто - последнее время софт все тяжелее и тяжелее становится. а основных регистров всего 8. отсюда проблемы c register pressure и так далее.

> а питон нормально себя ведёт *сегодня*?

Когда я собирал, то вёл нормально.
А вот собрав ssl я получил неправильный подсчёт rmd160 хешей. Питон для этого как раз ssl дёргает.

Сборка icc — лотерея. Бывает, что одна версия пакеты собирается и работает, следующая уже не собирается, ещё через одну собирается, но не работает.
Собирал ~80% пакетов в дженте. Потом плюнул, переключил всё на gcc и потихоньку, с обновлениями, полностью от icc избавился.
Гемора больше, чем профита.

Да... bash ещё собери, вдруг будет скрипты быстрее крутить. ;D

ну уж нет )))

Тогда я соберу) в случае чего есть чрут и dash

> Тогда я соберу) в случае чего есть чрут и dash

Тогда сразу сделай, пока ещё компилятор не переключил:

emerge -B bash
rm -f /bin/sh
ln -s /bin/dash /bin/sh
cp /etc/passwd /etc/passwd.copy
sed 's/\/bin\/bash/\/bin\/dash/g ' -i /etc/passwd

:)

Полет нормальный.

devl547@localhost ~ $ analyze-x86 /bin/bash
instructions:
cpuid: 5    nop: 226    call: 0    count: 315589
i686:    2261
mmx:    4265
sse:    2118
sse2:    665
sse3:    4
ssse3:    1
sse4.1:    39
sse4.2:    1
devl547@localhost ~ $ eix -c dev-lang/icc
[I] dev-lang/icc (11.1.072@09/01/10): Intel compiler suite for Linux
devl547@localhost ~ $ eix -c app-shells/bash
[I] app-shells/bash (4.1_p7@09/03/10): The standard GNU Bourne again

>-Ofast

нет бы сделать -fast, как у джентльменов

>$ analyze-x86 /bin/bash

cpuid: 5 nop: 226 call: 0

Бугога.

>Бугога

Натрави на любую софтину и увидишь столько же нопов.
man выравнивание.

>call: 0

Всё в одной функции?

>man выравнивание.

Открыл глаза, спасибо :}

>Всё в одной функции?

хз что там, у gcc то же самое показывалось.

Т.е. неправильно.

Пруф:

$ objdump -j .text -D `which gcc` |grep call |wc -l
1635

За этим к Сильви, это ее программа)

В дополнение к icc:
Там есть куча опции, которые похоже он не использует по дефолту (-opt-* ). Сейчас с ними экспериментирую.

analyze-x86 использует objdump -d , что вообщем то и очевидно если посмотреть код, у меня в bash вполне предостаточно call'ов насчитывает


$analyze-x86 /bin/bash
instructions:
cpuid: 2 nop: 1330 call: 12783 count: 136799
i686: 734
mmx: 15
sse: 20
sse2: 23

Я так предположу, что amd64 ваш analyze-x86 не поддерживает?

>cpuid: 2

Не слишком похоже на правильный результат.

только x86 (mmx, 3dnow, 3dnowext, sse - sse 4.2), на x86-64 даже не смотрела что там выдаваться может

можно было бы добавить еще westmere (aes), но времени пока нет

~ :$objdump -d /bin/bash |grep cpuid | wc -l
2
~ :$objdump -d /bin/bash |grep cpuid
80c40dd: 0f a2 cpuid
80c40f0: 0f a2 cpuid

что objdump -d выдало, то и посчитано, не больше, не меньше

>но времени пока нет

Сильви, я тогда поковыряюсь с твоим кодом, добавлю (у меня x86-64)

давно бы :)
ждём-с