Core2Duo FPU speed

По-моему у них он там даже не один :)

А может быть не Core2Duo, а gcc-developers?

а с чего вы взяли, что виноват процессор? ;)
может дело в коде...
почитайте А. Фога

Я уверен в том что виноват не процессор. Все дело в коде. SSE как раз наиболее эффективен в матричных вычислениях, ни один компилятор не способен сделать оптимизации эффективнее чем программист на асме.
http://democoder.ru/article/13

> а с чего вы взяли, что виноват процессор?

разве топикстартер _обвинял_ процессор?

ИМХО весь его спич был про то, как в нем хорошо реализована обычная float арифметика без SSE.

>весь его спич был про то, как в нем хорошо реализована обычная float арифметика без SSE.

Она хорошо реализована уже начиная с 80287 в прошлом тысячелетии...

>Вобщем, блок Floating Point реализован в нём просто отлично - с GCC получается, что принудительное использование SSE регистров вместо FP сопроцессора понижает скорость на ~20-30%; а переключение с типа float на тип long вообще не дало повышения производительности :-O

Яркий пример кроссплатформенного программирования без учета особенностей целевого процессора, такой код обречен на медленную работу.

Где-то на форуме gentoo пробегало, что с gcc вообще не рекомендуется использовать -mfpmath=sse, причем кажется это связано с glibc. Интересно было бы проверить скорость работы того же кода, но скомпилированного интеловским icc с -xP или -xT.

Небольшое сравнение - судя по нему разница в районе 10% на мультимедиа
http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html

>а переключение с типа float на тип long вообще не дало повышения производительности

А почему должно?

Потому что код для SSE* надо писать ручонками на ассемблере, а не полагатся на то что наоптимизировал компилятор.

P.S.: Простейшее преобразование rgb2yuv422 - fpu - кадр 1920x1080 обрабатывается почти две минуты (!). Инты со сдвигами - минуту. Ассемблерная функция с SSE2 - 2 секунды. При этом в первом случае различные -ftree-vectorize и -mfpmath=sse ни к чему не приводят, как тормозило так и тормозит.