сравнение производительности процессоров P4 с/без EM64T

spensnp

написал на C++ что-то типа Linpack Benchmark (диагонализация матрицы методом Гаусса, числа типа double. Написал потому, что 1000d есть только на фортране и ifc на него ругался ну и забавы ради).
скомпилил g++ и icc.
результат несколько странный:
g++:
arch: i686
model name: Intel(R) Pentium(R) 4 CPU 3.20GHz
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl cid xtpr
compiler flags: -m32 -march=pentium4 -O3
performance: 417.9 MFLOPS
arch: x86_64
model name: Intel(R) Pentium(R) 4 CPU 3.00GHz
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm
compiler flags: -m64 -march=nocona -O3
performance: 272.1 MFLOPS
та же ситуация и с icc. какой толк от em64t кроме снятия ограничения на максимально адресуемый объем памяти в 4Гб? Почему производительность даже уменьшилась? какая ситуация с amd64?
ЗЫ реальные вычислительные задачи считаются примерно с одинаковой скоростью.

sbs-66

Почему уменьшилась так тебе никто не ответит, ибо не телепаты. Либо компилятор лажанулся, либо ты что-то в коде очень неправильное написал. По идее должно было остаться примерно так же. Нужен x64 только для решения проблем с памятью, на самом деле. Плюс на очень специфических задачах получается заметное ускорение за счёт использования в 2 раза больших регистров. Сейчас даже и не припомню, что это за случаи такие. Вот в программе, которая простые числа мерсена ищет одна из эвристик в x64 работает в 2 раза быстрее, чем в 32-битном варианте, но к сожалению занимает эта эвристика от общего времени поиска доли процента. так что реально пользя только от того, что можно без гемороя использовать больше памяти, как виртуальной, так и физической.

spensnp

ибо не телепаты

вот собственно функция время работы которой измеряется (при помощи getrusage ):

void dge(double **A)

{

        unsigned int i,j,k;

        double c;

        for (k=1; k<DIM; k++)

        {

                for (i=k; i<DIM; i++)

                {

                        c = A[i][k-1] / A[k-1][k-1];

                        for (j=0; j<DIM; j++)

                                A[i][j] -= c*A[k-1][j];

                }

        }

}

массив A заполнен случайными числами
DIM ,размер массива, равен 1024. те вся марица занимает в памяти 8Mb.

sbs-66

Гым. Может при компиляции под x64 у тебя int 64-битный, соответсвенно операции с ним занимают больше тактов? Попробуй везде написать DWORD вместо unsigned int
PS. Хотя не факт, что поможет. Адресация в массиве может быть 64-битной. Может из-за этого и тормоза.

Marinavo_0507

не DWORD, а int32_t

sbs-66

ну м.б.
А чем плох DWORD?
Уже понял. DWORD определён как unsigned long, что не гарантирует, что он 4-байтный. Очень странно.

Olenenok

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

sbs-66

А что тогда использовать?

sbs-66

Ты вообще в курсе, что a[i] и *(a + i) - это одно и то же?

spensnp

Может при компиляции под x64 у тебя int 64-битный

да нет. sizeof(int) == 4

Marinavo_0507

> Почему производительность даже уменьшилась?
Насколько я помню, основная причина в том, что этот процессор - говно.
Другая причина: жырные указатели.
> какая ситуация с amd64?
Лучше. C более новыми интелами, как я читал, тоже лучше.

spensnp

C более новыми интелами

с Core_2 ?