Zpět na článek

Diskuze: Zákeřný útok dvoujádrem Phenom II

Nejsi přihlášený(á)

Pro psaní a hodnocení komentářů se prosím přihlas ke svému účtu nebo si jej vytvoř.

Rychlé přihlášení přes:

Uživatel bez registrace

Level 1

17. 2. 2009 14:00

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace na roote je analyza
http://www.root.cz/clanky/pameti-ctyristakrat-delsi-latenci-nez-procesory/

Ktora jasne hovori, ze AMD ma stale vacsi hruby vypoctovy vykon ako Intel s vynimkou P4 Willamette a Northwood, ktore mali dvojnasobny takt ALU oproti zvysku CPU.
Co AMD bzrdi je
1. nemoderne a nefektivne napiasny kod v Asembleri
2. 1pass cache flush

a zvacsienie L3 chache pri rovnakom pocte jadier sposbim, ze 1pass chache flus sposobi staru vzkonu na 4 takty namiesto 10 taktov pri mensej cache.

Zakernost riesenie je v tom, ze vacsou cache AMD znemozni kompilatoru umyslene sposobovat spomalenie AMD vkladanim kodu sposobujuceho 1pass cache flush.

V nanlyze su zasadne veci

Když ale programuji, tak mě zajímá, jak dlouho různé operace trvají, abych mohl program udělat co nejrychlejší. Částečně se to dá zjistit z datasheetu procesoru, ale na opravdovou výkonnost počítače má vliv ještě chipset a paměti, a proto jsem napsal program, který tuto rychlost zkusí přibližně změřit

Latency je čas, za jaký bude k dispozici výsledek, od doby, co instrukce načetla operandy, měřený v počtu taktů. V jednoduchých případech odpovídá délce pipeline zkrácené o načítací a dekódovací část.

Repeat Rate, někdy též zvaný Throughput. Říká, kolik taktů průměrně uplyne, než mohu spustit tutéž instrukci znovu (s jinými daty). Když například pracují všechny tři sčítačky zároveň, dostávám repeat_rate 1/3.

Když kompilátor optimalizuje nějaký program, měl by ideálně vědět víc než jen tato dvě čísla

Pro naše účely však postačí, když určíme špičkovou výkonnost procesoru pro některé často používané operace

Kromě měření operací které něco počítají, budeme také měřit, jak dlouho trvá, než dostaneme data z paměti. Nejprve jak dlouho trvá MOV dat z L1-cache. Alokujeme si nevelké pole. Toto pole vynulu1pass cache flushjeme a pak ho dvaatřicetkrát přečteme. Tím procesor pochopí, že ho má držet v L1-cache. Pak následuje test:

Na první pohled je vidět převaha AMD v množství vykonané práce na takt procesoru (zvláště u násobení a dělení). Zajímavou výjimkou je počítač VICTORIA (Intel P4), který dovede provést dvě závislá sčítání během jednoho taktu. Je to tím, že jeho sčítačka umí pracovat jak v náběžné, tak i v sestupné hraně hodin. V případě, že jsou data nezávislá, už lepší není, protože dovede spustit stejně jen tři instrukce zároveň, což dává stejný výkon, jako má většina ostatních procesorů.

Je vidět, že i FPU jednotka je u AMD lepší, jelikož je celkově rychlejší pro závislé instrukce a pro nezávislé má dokonce repeat-rate pro násobení rovno jedné. I nejlepší Xeon, který jsem testoval, měl repeat-rate dvě (nicméně Intely můžou být lepší v SSE, což jsem neměřil).

Řádek 00 imul testuje rychlost násobení „nula krát nula“. Na některých starších procesorech (i386) nebo třeba na ARM-7TDMI závisí doba násobení na číslech, která násobíme, přičemž 00 je nejrychlejší. Je vidět, že u nových procesorů tomu tak není.

Je pozoruhodné, že RDTSC trvá u některých Intelů až sto taktů. Přitom nevidím důvod, proč by musela být delší než jeden takt, když je to vlastně jen přečtení registru TSC čítače do %edx:%eax.

Řádek NaN+x fadd udává dobu instrukce fadd, která dostala jako operand NaN (Not a Number - výsledek operace 0/0). Jak je vidět, u AMD je pak latence (ale nikoliv repeat-rate) o jeden takt delší. Naproti tomu u Intelu provedení jedné takové instrukce může trvat až 1100 taktů (počítač GAIA). Důvod je mi neznámý

Dále je vidět, že novější Intely (FIREBALL1) mají chytřejší cache, která se nedá vyprázdnit pomoci „1pass cache flush“, kdežto AMD se takto nechá zmást. Sice má SOL5 již určitý náznak zlepšení, ale k FIREBALL1 má ještě daleko.

Zajímavý je repeat-rate 0,56 pro čtení z L1-cache u počítače SOL5 (a 0,65 pro OLDATHLON). Znamená to, že se většinou podařilo v (*) provádět všechny tři instrukce zároveň. Intely toto neumějí.

Ještě zajímavější ale je, že starší verze testovacího programu, která pro přesun dvou čísel v (*) místo tří instrukci používala čtyři tímto způsobem (před vstupem do bloku bylo %esi=%edi+%ecx):

movl (%edi), %eax

addl %ecx, %edi
movl (%esi), %ebx
addl %ecx, %esi

dávala následující výsledky:

Je vidět že zde už se AMDčku tolik nedařilo spouštět čtení najednou, na druhou stranu ale máme téměř dvojnásobné zrychlení čtení z paměti, a to u všech procesorů. Důvod pro toto podivné chování neznám, mám hypotézu, že procesor nebo řadič paměti možná dělá spekulativní načítání dat. Když mám čtecí instrukce rozmístěné tak, že se provádí jedna za druhou s rostoucími adresami, tak z toho pozná, jakou asi další část budu z paměti chtít, a snaží se ji připravit do cache.
- fotoba