>Теретически - можно. Практически - сложно (в большинстве случаев - неоправданно сложно).

специально для тех, кому сложно: http://wasm.ru/series.php?sid=17

> У людей, которые имеют опыт ручного копания траншей нет преклонения перед траншеекопателем? :) ИМХО, с точностью до наоборот :D

Так дело-то не в преклонении перед экскаватором, а в возведение принципов его работы в разряд эзотерики, недоступной обычному землекопу ;) Ну не всегда сразу очевидный и понятный код генерит компилятор, но понять-то его можно. Нет никакого таинства -O3 и т.п.

>Так дело-то не в преклонении перед экскаватором, а в возведение принципов его работы в разряд эзотерики, недоступной обычному землекопу ;)

Боюсь, что для человека, не сумевшего подняться уровнем выше землекопа, устройство траншеекопателя - это и есть эзотерика :D

(хотя развивать любые аналогии - это неправильно ;) )

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

Да. Хотя я не в теме вашего спора, но пять копеек всё равно кину - хороший компилятор не порождает ничего эзотеричного, но порождает код более эффективный, чем 99% (цифра от балды) вручную написанных на ассемблере программ. Это даже не считая того, что на более высоком уровне можно реализовать более сложный и эффективный алгоритм :)

...

Я имел довольно высокий «ассемблерный скилл». Но во времена i486 и Watcom C++ 11.x бросил страдать фигнёй и к ассемблеру с тех пор возвращался только один раз (в Embedded). Потому что увидел, что в целом ряде случаев компилятор порождает более эффективный код. И при этом требует на его написание в 10 раз меньше времени :)

...

Кстати, если интересно.
http://balancer.ru/2003/07/26/post-229767.html

Я пытался на ассемблере слепить бенчмарк для расчёта функции Аккермана.

Угробил минут 5 на написание и 45 минут на отладку. Считает ackr(3,8,8) за 2,88сек.

На O'Caml, который я видел впервые в жизни, я минут 5 искал, как на нём пишутся программы, минуту программу писал, заработала сразу. Считает за 2,08 сек.

На Си/Си++ лобовое решение, написанное за пару-тройку минут и за минуту-другую отлаженное считает 4,07 сек. Через час догадался использовать регистровую передачу параметров. Вышло 2.56сек.

На SP-Forth решение писал, наверное, минут 5 и отлаживал столько же. Ради скорости пришлось пожертвовать Форт-стилем и рефакторингом :) Считает за 2,1сек.

Потом посчитал для ackr(3,8,9) на уже тщательно вылизанных программах, вышло:

O'Caml - 19сек.
SPF4 - 21сек.
VC7 - 24сек.
asm - 26сек.
C# - 27сек.

...

GCC в тесте нет, так как был я тогда ещё виндузятником ;) Но он даже сегодня хуже, чем VC7.

> Да. Хотя я не в теме вашего спора, но пять копеек всё равно кину - хороший компилятор не порождает ничего эзотеричного, но порождает код более эффективный, чем 99% (цифра от балды) вручную написанных на ассемблере программ. Это даже не считая того, что на более высоком уровне можно реализовать более сложный и эффективный алгоритм :)

Да даже если компилятор генерит в 10 раз более плохой код, но делает это быстро, то он всё равно лучше любого ассемблера :)

> http://balancer.ru/2003/07/26/post-229767.html

Можно ускорить. Если выкинуть call и push/pop, будет сильно быстрее.

Только push/pop не выкинуть ;)

> GCC в тесте нет, так как был я тогда ещё виндузятником ;) Но он даже сегодня хуже, чем VC7.

gcc-4.4.0 на 3, 8, 9 выдаёт:

real    0m3.277s
user    0m2.709s
sys     0m0.475s

ocaml 3.11.0:

real    0m5.646s
user    0m4.707s
sys     0m0.847s

Gcc код здорово развернул, во всю использует conditional moves.

>Да даже если компилятор генерит в 10 раз более плохой код, но делает это быстро, то он всё равно лучше любого ассемблера :)

Ты, наверное, имел в виду не время компиляции, а время написания кода? :) Тогда - да. Поэтому я сегодня на PHP пишу. Хотя 15 лет назад за каждый такт воевал ;)

>Если выкинуть call и push/pop, будет сильно быстрее.

Не получится. Там несколькоуровневая нераскручиваемая рекурсия :) Глянь на первое сообщение темы, там задача описана.

>Только push/pop не выкинуть ;)

Угу, в том и прикол :)

>gcc-4.4.0 на 3, 8, 9 выдаёт:
>user 0m2.709s

>ocaml 3.11.0:
>user 0m4.707s

Я, кстати, не помню, отмечал потом в той теме или нет, но когда перешёл на Linux, то с удивлением обнаружил, что местный O'Caml много медленнее виндового :)

У тебя какое железо?

Те цифры были получены на PIII-1200/SDRAM (124МГц).

ICC profile guided optimization

прокомментируйте кто-нибудь данный (немного странный результат)
p7zip, сжатие одного и того же архива в 600 Мб

Прирост скорости в PGO составил 18.6%, в то время как с такими же флагами но без PGO 24.9%

статистику для PGO собирала бенчмарком и архивацией, т.е. все вроде как правильно...



GCC (default) 2350 Kb/s peak
real 4m27.885s
user 6m28.136s
sys 0m2.661s
+0%

GCC (pentium4, sse2) 2800 Kb/s peak
real 3m50.100s
user 5m35.349s
sys 0m2.373s
+14%

ICC 10.1 (Core2, SSSE3) 3200 Kb/s peak
real 3m20.661s
user 4m55.040s
sys 0m2.401s
+24.9%

ICC 10.1 (Core2, SSSE3, PGO) 3100 Kb/s peak
real 3m37.275s
user 5m9.787s
sys 0m2.420s
+18.6%

> Ты, наверное, имел в виду не время компиляции, а время написания кода? :) Тогда - да. Поэтому я сегодня на PHP пишу. Хотя 15 лет назад за каждый такт воевал ;)

Конечно! У меня сейчас в лэптопе более мощное железо стоит, чем 4 года назад был наш не самый паршивый продакшн-сервер ;) А через чур медленная, state of the art разработка никому не нужна. Другое дело, что совсем уж расслабляться тоже плохо.

> Не получится. Там несколькоуровневая нераскручиваемая рекурсия :) Глянь на первое сообщение темы, там задача описана.

Да, я уже поправил себя. Хотя, gcc умудрился в некотором виде циклы развернуть.

> У тебя какое железо?

Core2Duo T7500 (Merom, 2200 мгц, 4мб кэш).

>2200 мгц

Вот. И O'Caml отрабатвает за 4 секунды.

А под виндой на P3-1200МГц отрабатывал за 2. Как сейчас у тебя GCC :)

>все что они доказали что GCC плохо работает на солярисе и не более

лолшто?

>И да, в тесте очень не хватает Интеловского и Микрософтовского компиляторов. Боюсь, что оба они заметно обгоняют gcc по качеству оптимизации.

Это твой воспаленный мозг так решил?

> Вот. И O'Caml отрабатвает за 4 секунды.

Хм, SBCL за 8.2с управляется. Недурно...

Сравнивать GCC 4.2.* им сыкотно..

> Сравнивать GCC 4.2.* им сыкотно.. 

gcc-3.4.6:

real    0m4.137s
user    0m3.434s
sys     0m0.627s

gcc-4.3.0:

real    0m3.685s
user    0m3.360s
sys     0m0.286s

gcc-4.4.0:

real    0m3.277s
user    0m2.709s
sys     0m0.475s

gcc реально прогрессирует. 4.4.0 у 4.3.0 очень сильно отыгрывает.

>Сравнивать GCC 4.2.* им сыкотно..
Так ведь сравнивали выше (правда на Linux и с GCC4.3)
http://www.linux.org.ru/jump-message.jsp?msgid=3519239&cid=3519951

У меня правда получились немного другии цифры
gcc 4.3.2 (-O3 -fomit-frame-pointer -ffast-math) - 45.83
SunStudioExpress 2008/11 (-fast) - 40.51

Т.е. равенство, и это на том тесте, который якобы "Sun Studio проиграла в 3 раза".

>Re: Сравнение компиляторов GCC3, GCC4 и Sun Studio > Хотела я честно сравнить GCC и SunStudio, но вот после такого.... слив засчитан вообщем

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

А что касается линукса то если чуть-чуть пофиксить исходники гзипа все становится шоколадно: gzip - плюс/минус погрешность (gcc = 4.2)

Кстати на lame студия выигрывает 7-10 процентов у того же 4.2

А что значит "проприетарно"? Оно волне себе free for use. А если не нравится что код не открытый так вам что надо - на самом деле ехать или чтоб шашечки на такси нарисованы были?

гм. Странно. Тест крона-73 должен вообще работать без вычислений в run-time. В идеале. А так я померял с разными компиляторами, разными опциями оптимизации, на разные платформы и получил такое:

test_amd64_O2_gcc-3.4 3.44
test_amd64_O2_gcc-4.2 3.42
test_amd64_O2_gcc-4.3 4.50
test_amd64_O2nofp_gcc-3.4 3.43
test_amd64_O2nofp_gcc-4.2 3.44
test_amd64_O2nofp_gcc-4.3 4.48
test_amd64_Os_gcc-3.4 3.56
test_amd64_Os_gcc-4.2 3.51
test_amd64_Os_gcc-4.3 4.52
test_amd64_O3_gcc-3.4 3.43
test_amd64_O3_gcc-4.2 1.79
test_amd64_O3_gcc-4.3 2.15
test_amd64_O3nofp_gcc-3.4 3.43
test_amd64_O3nofp_gcc-4.2 1.77
test_amd64_O3nofp_gcc-4.3 2.17
test_x86_O2_gcc-3.4 4.12
test_x86_O2_gcc-4.3 4.56
test_x86_O2nofp_gcc-3.4 3.65
test_x86_O2nofp_gcc-4.3 4.49
test_x86_Os_gcc-3.4 4.22
test_x86_Os_gcc-4.3 4.67
test_x86_O3_gcc-3.4 4.13
test_x86_O3_gcc-4.3 1.64
test_x86_O3nofp_gcc-3.4 3.61
test_x86_O3nofp_gcc-4.3 1.36
./test_amd64_profile-gcc-4.3 1.64
./test_32_profile-gcc-4.3 1.50
./test_amd64_profile-gcc-4.3-nofp 1.65
./test_32_profile-gcc-4.3-nofp 1.44
./test_64_icc-O3 4.45

Лишний раз убедился что gcc - прекрасный компилятор. Сколько тестов не трердили что 'медленный' - каждый раз проверяю и убеждаюсь что кро поддержки кучи платформ и архитектур он ещё и лучший код генерит.

Посмотрел на код -O3 и понял почему его не надо использовать на больших программах. Ни с какой кэш не поместится.

Удивился, что profile-guided оказалось медленнее чем без оной.

Оказалось что быстрее всего код выполняется на x86, с -fomit-frame-pointer -O3 в gcc-4.3.

на amd64 в целом медленнее. И самый быстрый оказался gcc-4.2.

Не удивлён что 4.4 работает быстрее. Какая-то бага есть в 4.3 :)

Забавно, но: icc (11) полностью облажался.

Обязательно потестю на досуге VC2007 и Sun Stiduo12.

Немного переделал примерчик:
#include <stdio.h>

unsigned a(unsigned n,unsigned x, unsigned y);

int main(void)
{
printf("%d\n",a(3,8,9));
return 0;
}

unsigned a0(unsigned x, unsigned y)
{
return x+1;
}

unsigned a1(unsigned x, unsigned y)
{
if (!y)
return x;
else
return a0(a1(x,y-1),x);;
}

unsigned a2(unsigned x, unsigned y)
{
if(!y)
return 0;
else
return a1(a2(x,y-1),x);
}

unsigned a3(unsigned x, unsigned y)
{
if(!y)
return 1;
else
return a2(a3(x,y-1),x);
}

unsigned a(unsigned n,unsigned x, unsigned y) {
if (n==3)
return a3(x,y);
else if (n==2)
return a2(x,y);
else if (n==1)
return a1(x,y);
else if (!n)
return x+1;

if(y)
return a(n-1,a(n,x,y-1),x);

return 2;
}

Получились ещё более интересные результаты:
test_amd64_O2_gcc-3.4 2.55
test_amd64_O2_gcc-4.2 2.53
test_amd64_O2_gcc-4.3 0.00
test_amd64_O2nofp_gcc-3.4 2.54
test_amd64_O2nofp_gcc-4.2 2.55
test_amd64_O2nofp_gcc-4.3 0.00
test_amd64_Os_gcc-3.4 2.54
test_amd64_Os_gcc-4.2 0.00
test_amd64_Os_gcc-4.3 0.00
test_amd64_O3_gcc-3.4 1.70
test_amd64_O3_gcc-4.2 0.23
test_amd64_O3_gcc-4.3 0.00
test_amd64_O3nofp_gcc-3.4 1.72
test_amd64_O3nofp_gcc-4.2 0.22
test_amd64_O3nofp_gcc-4.3 0.00
test_x86_O2_gcc-3.4 2.85
test_x86_O2_gcc-4.3 0.00
test_x86_O2nofp_gcc-3.4 2.47
test_x86_O2nofp_gcc-4.3 0.00
test_x86_Os_gcc-3.4 2.94
test_x86_Os_gcc-4.3 0.00
test_x86_O3_gcc-3.4 2.60
test_x86_O3_gcc-4.3 0.00
test_x86_O3nofp_gcc-3.4 2.31
test_x86_O3nofp_gcc-4.3 0.00
./test_amd64_profile-gcc-4.3 0.00
./test_32_profile-gcc-4.3 0.00
./test_amd64_profile-gcc-4.3-nofp 0.00
./test_32_profile-gcc-4.3-nofp 0.00
./test_64_icc-O3 2.51

Т.е. icc обломался ещё раз. Прогресс в gcc налицо.

>Удивился, что profile-guided оказалось медленнее чем без оной.

выше есть мой тест Intel PGO с 7zip
вот и меня тоже удивляет, пересобрала еще LZMA, за планку брала GCC, Pentium4+SSE2 (обычные параметры для сборки "домашних" пакетов, ноут у меня такой...)


GCC -O2 - _минус_ 5.8%
GCC P4,SSE2 - 0% (планка для сравнения)

ICC, CORE2 +11.8%
ICC, CORE2,PGO +14.0 %
то есть PGO себя чуточку показало

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

если сравнивать скорость кода генерируемого GCC, то максимальна она (код на C) 3.4.6 , 4.2.x показывает самую низкую производительность,
4.1.х - средне, 4.3.3 достаточно быстро и GCC 4.4.0 очень приличную скорость, то есть радует что работа в этом направлении ведется и ведется активно. 4.0.х ветку я для сравнения подходящей не считаю, в отличие от "аналитиков Фороникс"

>если сравнивать скорость кода генерируемого GCC

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

Dear Silvy,

Я посал про тест крона, где icc явно оказался не у дел, 4.3 показал себя во многих тестах хуже чем 4.2.

И ни один компилятор не оправдал моих надежд на вычисление функции во время компиляции, что явно возможно.

Более того, icc конкретно проиграл даже на упрощённом тесте.

-ipo ему не помогает на этом тесте.

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

В вашем тесте, на x86 -fomit-frame-pointer был?

>да , заранее скажу что тестировала с gzip и его производительностью

Лучший способ оптимизировать gzip - это собрать себе pigz и пользоваться ним:)

мне не очень интересны тесты ради тестов, это синтетика,
хотя конечно очень показательная, мне интересно сделать тесты с реальными приложениями, gzip в этом плане отличается простотой сборки, совместимостью практически со всеми компиляторами, хотя вот СанСтудия его отказалась собирать :) А также простой методикой проверки производительности самого кода, ассемблерных вставок в gzip нет.

-fomit-frame-pointer был во всех случаях


2 Led, производительность gzip'a даже без оптимизации меня устраивает, pigz есть, и есть pbzip2, bzip2smp что кстати лучше в том плане что bzip2 более медленный по сравнению с gzip,
еще бы lzma найти с поддержкой потоков, хотя Тукаани что то делает в этом направлении, но неубедительно и совместимость с старым lzma поломал в новых `XZ`

>есть pbzip2, bzip2smp что кстати лучше в том плане что bzip2 более медленный по сравнению с gzip, еще бы lzma найти с поддержкой потоков, хотя Тукаани что то делает в этом направлении, но неубедительно и совместимость с старым lzma поломал в новых `XZ`

Многопоточные компрессоры всегда будет давать худшую компрессию, по определению.

Поэтому для быстрого сжатия - pigz или аналоги, я bzip2 и lzma стОит использовать только если время сжатия некритично, но хочется достичь максимального сжатия, поэтому их многопоточные варианты (заведомо более проиграшные) ИМХО не нужны.

bzip2smp
pbzip2
дают идентичный результат однопоточному bzip2

единственное что первый только сжимает и только stdin 2 stdout
а второй только уже готовый файл

для realtime сжатия есть lzo
для всего остального - субьективно по нуждам и тому какой процессор.


7zip (p7zip) - двухпоточный, хотя неспособен утилизовать второе ядро более 50% (т.е. 150% получается нагрузка примерно), но это тоже лучше чем ничего

>Многопоточные компрессоры всегда будет давать худшую компрессию, по определению.

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

>Смелое заявление. Главное, громко и с пузырями.

Ок, тогда тихо и без пузырей, многопоточный код, не снижающий уровень сжатия, для указанных выше bzip2 и lzma - в студию! И я признаю, что ступил:)

для lzma не выложу. потому что его нет, найдете - киньте ссылочку, давно ищу


для bzip2 (вот не читаете мои сообщения) - сами напросились

http://compression.ca/pbzip2/

> для bzip2 (вот не читаете мои сообщения) - сами напросились
> http://compression.ca/pbzip2/

$ time pbzip2 -9 -k dfly-gui-2.2.0_REL.iso
454.05user 12.44system 4:24.66elapsed 176%CPU (0avgtext+0avgdata 0maxresident)k
88inputs+0outputs (0major+1542566minor)pagefaults 0swaps
$ mv dfly-gui-2.2.0_REL.iso.bz2 dfly-gui-2.2.0_REL.iso.pbz2
$ time pbzip2 -9 -r -k dfly-gui-2.2.0_REL.iso
447.87user 9.13system 4:22.81elapsed 173%CPU (0avgtext+0avgdata 0maxresident)k
920inputs+0outputs (1major+434633minor)pagefaults 0swaps
$ mv dfly-gui-2.2.0_REL.iso.bz2 dfly-gui-2.2.0_REL.iso.rpbz2
$ time bzip2 -9 -k dfly-gui-2.2.0_REL.iso
423.49user 4.90system 7:14.96elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2027minor)pagefaults 0swaps
$ ls -l dfly-gui-2.2.0_REL.iso*
-rw-r--r-- 1 led led 1269006336 лют 16 10:32 dfly-gui-2.2.0_REL.iso
-rw-r--r-- 1 led led  494774334 лют 16 10:32 dfly-gui-2.2.0_REL.iso.bz2
-rw-r--r-- 1 led led  495072030 лют 16 10:32 dfly-gui-2.2.0_REL.iso.pbz2
-rw-r--r-- 1 led led  494724210 лют 16 10:32 dfly-gui-2.2.0_REL.iso.rpbz2

Т.о. файл у pbzip2 получается всё же больше:) С -r только меньше получился, но "так не честно":)

Да, забыл добавить: это всё на двухядерном процессоре.

612904960 linux28.7.tar

$pbzip2 -9v linux28.7.tar
Parallel BZIP2 v1.0.3 - by: Jeff Gilchrist [http://compression.ca]
# CPUs: 2
110289814 linux28.7.tar.bz2

$bzip2 -9v linux28.7.tar
109535518 linux28.7.tar.bz2
разница не такая уж и большая, но есть.. хорошо, другой код, просто когда давала ссылку не было возможности проверить на двухядерном


$cat linux28.7.tar |bzip2smp -9v > linux28.7.tar.bz2
bzip2smp: No hyperthreading detected.
bzip2smp: CPUs detected: 2
bzip2smp: Threads to use: 2
109535518 linux28.7.tar.bz2

то есть также как и bzip2
ссылка - http://bzip2smp.sourceforge.net/
сжимать файл он не умеет, только поток с stdin на stdout

Да, так и есть, согласен.

Правда (чего и следовало ожидать) памяти на каждый CPU он огребает не менее 7,5М. Для lzma этот подход врядли представляет практическую ценность: там для -9 уже требуется 311М памяти при упаковке и, что более критично, 33М при распаковке.

>Поэтому я сегодня на PHP пишу. Хотя 15 лет назад за каждый такт воевал ;)

Такая ж история. Последний раз, когда использовал ассемблер, убил целый выходной, получил прирост производительности в пределах погрешности. Потом немножко подумал, ввел одну переменную (4 байта), получил ускорение в 2-5 раз. С тех пор ассемблер не трогаю

компиляторы мож и хорошие а ide которая идёт к семейству компиляторов херовая.. сделана на яве,которая под линухом не лучшим образом работает.