AMD vs Intel

Действительно ли это было адекватное сравнение? Потому как можно заточить код под одну из архитектур.

Проводилась только общая оптимизация (-О2) без какой либо заточки подконкретный проц. Аасемблер применялся по минимуму для запаковки (unpklpd, unpcklps, shufps) распаковки (movhps, movhpd, movlps, movss, movshdup) и пакетной армфметики (addps, addpd, mulps, mulpd, divps, divpd, sqrtps, sqrtpd) + команды перемещения данных (movapd, movaps). Собственно как алгоритмы в голову пришли так и закодировались. Полагаю что это общий набор команд (заявленный к поддержке в АМД) и в его применении нет заточки под конкретный арх, а специально я оптимизацию не проводил (и на асме пишу не так часто чтоб в голове оптимизировать)

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

gcc какие-то потуги по заточке под конкретный процессор делает, если указать нужный -march, но у него это плохо получается.

Собственно говоря, даже у интела netburst (pentium-4) и core - уже две архитектуры с колоссальной разницей.

То что архитектуры разные и так видно. Что такое SIMD написано в амдшных доках черным по белому - ускорение обработки данных путем их параллельной обработки. И где собственно мопасан? Не надо тыкать в оптимизацию, она не использована. А оспорить кривость архитектуры у одной фирмы по крайне мере странно.

Какая кривость? В чём кривость? gcc кривой? Это давно известно, что у него проблемы с оптимизацией.

АМД кривой. В том что SIMD обработка ТОРМОЗИТ вычисления а не ускоряет их, хотя этот факт фанатикам АМД понять недано

Ну покажи свой код, который на amd тормозит.

А исходники тестов показаны не будут?
Онанимусу верить на слово? Ну-ну ...
Так каждый может создать топик и с обратным утверждением.

Пожалуйста критикуйте:
Без упаковки:
main.cc:
#include <iostream>
#include <time.h>
#include <stdlib.h>

extern void test(double&, double, double);

int main()
{
double f1 = 3;
double f2;

double s_ptime = clock();

for (long i=0; i<20000000000; i++)
{
test(f2, f1, 1);
}

double ptime = (clock() - s_ptime);
std::cout << "\t cpu: " << ptime << " ticks\n";
std::cout << f2 << "\n";
}
tst.cc:
#include <math.h>

void test(double& f1, double f2, double f8)
{
f8 *= f8;
f2 *= f2;
f1 = 1/sqrt(f2+f8);
}

С упаковкой:
main.cc:
#include <iostream>
#include <time.h>
#include <stdlib.h>

typedef double __m128d __attribute__ ((__vector_size__ (16)));

extern "C" __m128d SIMD_pack_double(double, double);
extern "C" void SIMD_unpack_double(double&, double&, __m128d);
extern "C" __m128d test(__m128d, __m128d);

int main()
{
double d10 = 3;
double d20 = 4;

double d1,d2;


double s_ptime = clock();

for (long i=0; i<10000000000; i++)
{
__m128d pd = SIMD_pack_double(d10, d20);
__m128d p1 = SIMD_pack_double(1, 1);
pd = test(pd, p1);
SIMD_unpack_double(d1, d2, pd);
}

double ptime = (clock() - s_ptime);
std::cout << "\t cpu: " << ptime << " ticks\n";
std::cout << d1 << " " << d2 <<"\n";
}
my.s:
.text
.globl test
.type test, @function
.globl SIMD_pack_double
.globl SIMD_unpack_double
.type SIMD_pack_double, @function
.type SIMD_unpack_double, @function


test:
mulpd %xmm0, %xmm0
mulpd %xmm1, %xmm1
addpd %xmm1, %xmm0
divpd %xmm1, %xmm1
sqrtpd %xmm0, %xmm0
divpd %xmm0, %xmm1
movapd %xmm1, %xmm0
ret

SIMD_pack_double:
unpcklpd %xmm1, %xmm0
ret

SIMD_unpack_double:
movhpd %xmm0, (%rsi)
movlpd %xmm0, (%rdi)
ret

Отмечу что вычисляется ОДИНАКОВОЕ количество операций, поэтому и цикл в первом случае длиннее чем во втором в два раза. На моих машинках соотношение (без упаковки/с упаковкой)
AMD 44477/55920
Intel 48016/28671
команды по сборке:
g++43 -msse3 -o tst.o -c -O3 tst.cc && g++43 -c -O3 -o main1.o main1.cc && g++43 -o pack1 main1.o tst.o
g++43 -msse3 -o my.o -c my.s && g++43 -c -O3 -o main.o main.cc && g++43 -o pack main.o my.o

Расскажите мне где тут чего оптимизировано под корку интеловскою что атлону так плохо?

И характеристики машинок тоже брось заодно.

Плиз: Intel Core2 Quad Q9450 2.66MHz 1333FBS 12M L2 Intel DG33BUC (iG33) 8 GB RAM 800MHZ Patriot

AMD Athlon 64 X2 4800+ Brisbane 2.5MHz 1M L2 HT 2000MT/s (1000MHz) Asus M2N-VM SE (nVIDIA GeForce 6100 + nVIDIA nForce 430) 4 GB RAM 800MHz Patriot

На обоих стоит FreeBSD 7-STABLE, компилировалось gcc v 4.3.2 20080626 (prerelease)

Какие еще доказательста вам привести? Полагаю какие и сколько винтов не играет роли, сетевухи тоже неважны, объемы памяти разные но это тоже по барабану ибо такая простая прога влезает в 5 мегов озу без надрыва. Так что обвинения во вранье безосновательны.

Сейчас нужная ось поставится на оптерон, проверю

мда

Проверь будет интетересно на серверный проц от АМД посмотреть...

Итак... :)

RHEL-5.2 x86_64, gcc 4.1.2

$ cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Xeon(R) CPU            5110  @ 1.60GHz
stepping	: 6
cpu MHz		: 1596.044
cache size	: 4096 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
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 nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm
bogomips	: 3194.65
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Xeon(R) CPU            5110  @ 1.60GHz
stepping	: 6
cpu MHz		: 1596.044
cache size	: 4096 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
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 nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm
bogomips	: 3192.11
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

$ g++ -o main main.cc

cpu: 1180000

$ g++ -o main -O1 main.cc

cpu: 1100000

$ g++ -o main -O2 main.cc (g++ с -O3 уже цикл вырезает)

cpu: 1100000

$ g++ -o main-pack -msse3 main-pack.cc my.S

cpu: 580000 ticks

$ g++ -o main-pack -msse3 -O1 main-pack.cc my.S 

cpu: 630000 ticks

$ g++ -o main-pack -msse3 -O2 main-pack.cc my.S 

cpu: 610000 ticks

$ g++ -o main-pack -msse3 -O3 main-pack.cc my.S 

cpu: 610000 ticks

Fedora-9 x86_64, gcc 4.3.0

$ cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz
stepping	: 11
cpu MHz		: 800.000
cache size	: 4096 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
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 syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
bogomips	: 4394.34
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz
stepping	: 11
cpu MHz		: 800.000
cache size	: 4096 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
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 syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
bogomips	: 4388.79
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

$ g++ -o main main.cc

760000 - 790000

$ g++ -o main -O1 main.cc

770000 - 790000

$ g++ -o main -O2 main.cc

770000 - 790000

$ g++ -o main-pack -msse3 main-pack.cc my.S

400000 - 420000

$ g++ -o main-pack -msse3 -O1 main-pack.cc my.S 

400000 - 420000

$ g++ -o main-pack -msse3 -O2 main-pack.cc my.S 

430000 - 440000

$ g++ -o main-pack -msse3 -O3 main-pack.cc my.S 

420000 - 430000

RHEL-5.2 x86_64, gcc 4.1.2

cpufreqd в RHEL плохо на амд работает, циклов в 10 раз больше сделал, и стоит смотреть на меньшую цифру.

$ cat /proc/cpuinfo 
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 67
model name	: Dual-Core AMD Opteron(tm) Processor 1220 SE
stepping	: 3
cpu MHz		: 1000.000
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips	: 2001.85
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 67
model name	: Dual-Core AMD Opteron(tm) Processor 1220 SE
stepping	: 3
cpu MHz		: 1000.000
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips	: 2001.85
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc


$ g++ -o main main.cc

6140000 - 656000

$ g++ -o main -O1 main.cc

3520000 - 4090000

$ g++ -o main -O2 main.cc

3140000 - 3620000

$ g++ -o main-pack -msse3 main-pack.cc my.S

5140000 - 5900000

$ g++ -o main-pack -msse3 -O1 main-pack.cc my.S 

4160000 - 4650000

$ g++ -o main-pack -msse3 -O2 main-pack.cc my.S 

4030000 - 4690000

$ g++ -o main-pack -msse3 -O3 main-pack.cc my.S 

4150000 - 5020000

>model name	: Dual-Core AMD Opteron(tm) Processor 1220 SE
>stepping	: 3
>cpu MHz	: 1000.000
>cache size	: 1024 KB

RHEL-5.2 врёт на счёт проца. На самом деле он:

cpu MHz: 2800+
cache size L1: 256kb
cache size L2: 2048kb

> Действительно ли это было адекватное сравнение?

Глупый вопрос. Интелевский FUD сейчас везде. У них очень серьёзные проблемы с техническим потенциалом и маркетингом.

Ещё: кол-во циклов было уменьшено в 1000 раз (не охота долго ждать), на последнем тесте - в 100 раз, потому что ядро поднимает частоту процу с некоторой задержкой. На Xeon'е частота фиксированная, на Core2Duo тоже прыгает, но нет проблем с такой большой задержкой, как в случае с AMD (это баг ядра, вроде). Для машин с прыгающей частотой проводилось по 5 замеров, приведено наилучшее и наихудшее время.

> У них очень серьёзные проблемы с техническим потенциалом и маркетингом.

Да всё у них нормально сейчас и с тем, и с другим. Как свой поганый NetBurst умертвили, так опять хорошо стало.

Ну вот вы и получили -32% т. е. падение производительности при SIMD оптимизации на АМД проце, чего на интелях вам продемонстрировать не удалось. Там на против рост производительности. Так вот собственно и напрашивается вывод об архитектуре некоторых процессоров. Вообще-то народ парится SIMD оптимизацию сделать чтобы работало быстрее а не тормозило. Значит не зря сие процы столько стоят.

ЗЫ: Не у кого фонома нет помереть? Интересно блин... он просто мертво рожденный или совсем выкидышь...

Касательно последних строк в main файлах где вывод на консоль, то они для того чтобы оптимизация -O3 не убивала цикл...

>типичные вычисляемые величины: >sqrt(x^2+y^2), x^2+y^2, 1/(x^2+y^2), (x+y)^2, 1/sqrt(x^2+y^2)

если точность устраивает, можно взять приближенный алгоритм 1/sqrt(x) из Quake3

Знаете товарсчь, приближенный алгоритм есть в самой системе команнд SSE, SSE2 на уровне машинных команд, так что из кваки ничего тырить не нужно. Просто дело в том что системы мат моделирования немного отличаются от стрелялок по назначению, точность полученных результатов играет не последнюю роль... Задача в том как получить более точный результат за меньшее время, для этого в частности и используется SIMD - за то же время можно провести больше расчетов а следоательно увеличить точность. Но на практике с АМДшными процами такая философия рушится как карточный домик.

ЗЫ: НЕ ЭКОНОМТЕ НА ВЫЧИСЛИТЕЛЬНЫХ СЕРВЕРАХ, А ТО ЖАЛЕТЬ ПРИДЕТСЯ.

> ЗЫ: НЕ ЭКОНОМТЕ НА ВЫЧИСЛИТЕЛЬНЫХ СЕРВЕРАХ, А ТО ЖАЛЕТЬ ПРИДЕТСЯ.

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

> ЗЫ: Не у кого фонома нет помереть? Интересно блин... он просто мертво рожденный или совсем выкидышь...

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

А можно для тупых - каким образом улучшится производительность при уменьшении кеша?

> L1 каждый раз инвалидируется при переключении контекста.

Уверенно сказал?

> Уверенно сказал?

Собственноушно от Ульриха Дреппера слышал...

Собственно, вот почему: L1 работает в адресном пространстве контекста. Когда контекст меняется, данные в L1 инвалидируются, потому что указывали на данные не того пространства.

Вот тут много интересного написано: http://people.redhat.com/drepper/cpumemory.pdf