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

Блин, метки поставить забыл :(

Ну, я думаю, к GMP это все-таки не относится.

> Блин, метки поставить забыл :(

В таком случае нужно не забывать писать какие именно забыл :)

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

очень хорошо.

GCC станет быстрее ?

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

Смотря какой цикл, и смотря какого человека. По моим наблюдениям, gcc бывает весьма далек от совершенства.

> GCC станет быстрее ?

Если и станет, то незначительно. бОльшую часть своего времени gcc проводит отнюдь не в процедурах gmp. На результаты компиляции это тем более влиять не должно.

про результаты компиляции понятно,
но уж больно GCC 4.4.x завязан на

GMP+MPFR+ добавились еще и PPL+CLOOG

checking how to link with libgmp... /var/tmp/lib/libgmp.a
checking how to link with libgmpxx... /var/tmp/lib/libgmpxx.a /var/tmp/lib/libgmp.a
checking for the GMP library version 4.1.3 or above... no
configure: error: Cannot find GMP version 4.1.3 or higher.


PPL кстати новая libgmp не нравится )

configure:13421: ./conftest
Floating point exception

причем вот.. так

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

Когда работаешь с очень большими числами и это главная задача программы - там очень полезны cpu-специфичные вещи.

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

> запихнуть переменные в регистр - GCC умеет может и лучше человека...

В какой регистр залезет целое десятичное число в 120 знаков? А если 2 таких числа умножить?

совместимость с BDSM P

Блин, а я подумал причем тут генеральный медицинский стандарт...

станет ли GCC быстрее?

сборка кода gmp 4.3.0 C и С++
-O3 -fomit-frame-pointer -march=core2 -ftree-vectorize -mfpmath=sse -mmmx -mssse3

gcc 4.4.0 20090412 / gmp 4.2.4 / mpfr 2.4.1 /ppl 0.10 /cloog 0.15
real 1m49.190s
user 1m18.575s
sys 0m27.142s

gcc 4.4.0 20090415 / gmp 4.3.0 / mpfr 2.4.1 / ppl 0.10.1 / cloog 0.15.3

real 1m50.317s
user 1m18.572s
sys 0m26.395s


ну вообщем понятно ^_^

угу, разница в рамках статистической погрешности, поэтому этот "тест" ни о чем не говорит

отрицательный результат - тоже результат )

В данном случае никакого ускорения за счет GMP не получилось и наверняка в сборке других пакетов общего плана и не будет

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

(запихнуть переменные в регистр) != (запихнуть все переменные в регистр)

проблема в том, что некоторые возомнившие себя крутыми ассемблеристами личности думают иначе.

> проблема в том, что некоторые возомнившие себя крутыми ассемблеристами личности думают иначе.

Разве они все не вымерили ещё?

> проблема в том, что некоторые возомнившие себя крутыми ассемблеристами личности думают иначе.

"крутой ассемблерист" пишущий на ассемблере x86 - помесь мазохиста с Наполеоном. Не бывает.

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

Навряд ли это относится к GMP - его ой как навряд ли идиоты писали, или будут конкретные цифры по GMP+asm vs GMP+c?

>Разве они все не вымерили ещё?

Нет. Рядом второй сидит.

Значит ли это, что санктъпетербургские физики таки смогут моделировать ядерные взрывы на недавно подаренных SUN кластерах? Грили что аппаратной точности не хватает, дык вот вам программная эмуляция. Даже если в 10 раз медленнее, то особой разницы нет - 3 дня процесс считать или месяц.

> Значит ли это, что санктъпетербургские физики таки смогут моделировать ядерные взрывы на недавно подаренных SUN кластерах?

Нет. GMP сто лет в обед, если они про неё раньше не знали -- то им оно либо не поможет, либо бесполезно.