To vypadá opravdu slibně :)

App kdy se toho máme dočkat?

takze vlastne rok po Conroe.. Intel rozjel asi dobry hype, kdyz za 60dni prodal 5mil Conroe.. a vcera "beatnul" predpovedni analytiku o 5centu...
uvidime rekl slepy...

fotoba - nema to nahodou byt "DRUHY" v tom porovnani AthlonXP a Athlon64 (v puvodnim clanku je slovo "latter" - "pozdejsi, druhy" a je to i celkem logicke ;) )

Fotoba: Bohuzel nemas pravdu. 128-bitove skalarni MUL ani DIV neexistuji. Tady se jedna o SIMD vektory 4x 32-bit nebo 2x64 bit. Takze zrychleni bude "pouze" dvojnasobne. V soucasnosti se totiz musi 128-bitove vektory pocitat nadvakrat.

fotoba: Ty jsi pouze teoretik, ja praktik. SSE/SSE2/SSE3 pouzivam kazdy den a muzu ti garantovat, ze krome 128-bitovych posuvu NEMAJI zadne dalsi 128-bit operace. Registry samozrejme jsou siroke 128-bit, ale obsahuji 2 nebo ctyri nezavisle cisla. Treba instrukce MULPS vynasobi 4 32-bitove floaty jinymi 4 32-bitovymi floaty. Podobne MULPD vynasobi 2 64-bitove floaty jinymi 2 64-bitovymi floaty. Zadna domnela instrukce MULPQ, ktera by vynasobila 1 128-bitovy float jinym 128-bitovym floatem (zatim) NEEXISTUJE !!!!

fotoba:
No, takže tu máme dual chanel pro paměti, 64 x 32 bit, dualcore a další. Mají jedno společné: teoreticky jsou všechny až "až" 2x rychlejší, prakticky je ten přínos obvykle kolem několik %, často i žádný.

kuba: Intel uz ma jasno v SSE4 davno ... ono totiz uz v Intel procesorech je ;-) .

Bespi: Ne tak docela, Intel totiz ve vsem dela pekny bordel. Conroe nemaji SSE4, ale SSSE3 :).

fotoba: Mas v tom poradny zmatek. Ty clanky jsou v poradku, ale vyvozovane zavery ne. Spojene FP a SSE jednotky maji jiz soucasne K8. Jediny rozdil je ten, ze K8L je maji dvojnasobne tak siroke a tim padem je mozne spocitat 2x tolik FP cisel, nez ted. Bez zmeny instrukcni sady. Soucasne instrukce totiz vetsinou potrebuji na vykonani dva takty. Tot vse. :)

2fotoba: "The performance advantage of running in 64-bit mode is anywhere between 10 and 300 percent faster than the same computer in 32-bit mode, depending on what you're doing." - na to můžeš leda tak zapomenout, přínos 64bit je ve většině případů mezi cca. -2 až +10 %. 300 % možná tak v čisté syntetice.

Jestli to spravne chapu??? AMD nezmenilo mnozstvi instrukci zpracovanejch za takt za 3 na 4 jako Intel u C2D. Misto toho zvetsili FPU/SSE jednotku do sirky, takze vlastne nafoukli instrukci misto aby zpracovavali 2 vedle sebe.
A druha vec, pokud to opet spravne chapu, tak AMD by v pripade spravne predpovezenyho obsahu L2 melo pocitat rychlejc, protoze kazdy jadro bude mit v L2 nafedrovany svoje data. Navic by asi mela mit agresivnejsi casovani nez ohromna 4MB L2 u Conroe.

PS:Je mozny ze naprosto matu pojmy a dojmy.

Eagle_not_registered: Nemáte pravdu, aneb kolik aplikací jste v 64b modu skutečně provozoval?

2Ritchie: Zkoušel jsem jich několik a všechny běžely plus mínus stejně rychle. Ostatně on není žádný důvod, proč by měly běžet rychleji... tedy až na 64bit integery, které se ale beztak běžně nepoužívají. Nebo snad víte o nějakém důvodu?

64bitovou architekturu jsem testoval už před třemi lety a zrychlení proti 32bitové architektuře je v Linuxu průměrně 20%. Jsou ale i výjimky. Např. lame mp3 do wavu v 32bitech 3 minuty a 64bitech 1 minutu. Komprese a dekomprese přes gzip a bzip nezaznamenala větší rozdíl.

2progmaster: LAME 32bit vs. 64bit zkompilovaný dobrým kompilátorem = rozdíl nula. Jestli jsi měl tak velký rozdíl, byla příčina jinde - zřejmě ve špatné 32bit kompilaci nebo v použití různé verze.

Eagle_not_registered: Nejde len o 64-bitove registre, ale celkovo ich je o 8 viac (vseobecnych) a pri volani funkcii sa prve styri argumenty posielaju priamo cez registre namiesto cez zasobnik. Takisto aplikacie vyuzivaju instrukcie, o ktorych vedia, ze su sucastou AMD64 a EM64T, kedze bezia v 64-bit mode. 64-bitove registre su len spicka ladovca.

2brano: Registrů není víc, neboť v moderním out-of-order procesoru se beztak přemapovávají do registrového pole. Víc viditelných registrů pro programátora může jen zlepšit paralelizovatelnost výpočtů, moderní procesor je ale dost úspěšný i bez této pomůcky. Funkční volání může zaznamenat přínos, to je pravda. Otázkou je o kolik. Zase nevýhodou je větší pointer, což naopak zpomaluje. AMD64 instrukce jsou ekvivalentem k x86, takže jakápak výhoda?

Eagle: Nechapu, o co Vam jde. Oni maji pravdu. Vyhody 64-bit jsou neoddiskutovatelne. Mnohem vic mista v registrech (nejen GP, ale i SSE) se pri dobre napsanem kodu projevi. Optimalizace na urovni procesoru jsou velmi limitovane. Dobry kompilator (nebo lepe dobry programator) dokaze optimalizovat mnohem lepe.
Navic, jak zde bylo spravne uvedeno, posouva se "lowest common denominator" nahoru. Veskere floating-point vypocty nyni mohou (resp. musi) vyuzivat SSE2 a existuji i dalsi drive "volitelne" instrukce - treba CMOV. Existuji algoritmy, ktere jdou zrychlit i o vice, nez tech 300%...
Tohle samozrejme neplati vzdy. Ne vsechno jde (nebo se chce) pro 64-bit optimalizovat. Pripady, kdy dojde k poklesu vykonu, jsou casto spojeny s nemoznosti pouzit existujicich rucne psanych FPU, MMX a 3DNow! rutin v 64-bit modu.

2xR: To přece není pravda. Zkoušel jsem zkompilovaný kód jednou 32bit a podruhé 64bit a výsledky byly stejné. Jaká hardwarová výhoda tam je? Až na 64bit aritmetiku žádná. Víc místa v registrech je k ničemu, procesor tyhle registry stejnak nezná, má svoje hardwarové pole (maximálně se ušetří pár POP a PUSH instrukcí v dekodéru, procesor je ale hardwarově stejnak nejspíš nevykonává). Naopak další registry znamenají delší instrukci, tj. větší zátěž na rychlost cache a dekodéry - např. Conroe kvůli tomu nemusí zvládnout dekódování 4 instrukcí za takt, protože jeho propustnost do dekodéru je 16byte/cyklus. Čili co ušetřím na PUSH/POP, to zase ztratím na prefixu. Nějaká ztráta taky plyne z většího pointeru.
A co se SIMD a dalších vylepšení jako CMOV a FCMOV týče, tak to je výhoda jen pro jednodušší konstrukci programu, tyto instrukce je možné využít i u 32bit. A pokud porovnám výkon programů s identickou optimalizací, jednou 32bit a podruhé 64bit, tak prostě s největší pravděpodobností budou mít stejný výkon (pokud nebudou používat 64bit aritmetiku, což je poměrně neobvyklé). BTW, x87 je dle dokumentace AMD stále přítomno a je možné ho použít.
Takže celkově vzato je 64bit velmi důležité kvůli podpoře víc jak 4 GB RAM, ale výkon navíc až na výjimky nepřinese.

"Víc místa v registrech je k ničemu" - OMG
Tohle uz je trochu moc. Pisu tuny kodu v assembleru a jsem naprosto zoufaly z maleho poctu registru. Nektere algoritmy kvuli tomu vubec nejdou napsat ! A ty co jdou, jsou strasne pracne. Clovek porad musi premyslet, co z ktereho registru vyhodit a kde co vlastne ma. A v SSE nejsou zadne push/pop. Tam kdyz chybi registry, je to v pytli. Kdyby bylo 128 SSE registru (tak jako u nekterych jinych architektur), zrychlilo by to muj kod 3x.

2xR: Jak už jsem řekl, CPU ty registry stejnak nepoužívá, má svoje hardwarové registrové pole, které je u 64bit stejně velké jako u 32bit. Takže to možná zjednoduší programování, ale na výkon to žádný převratný dopad mít nebude. A pokud děláte náročné algoritmy, doporučuju použít C++ a dobrý kompilátor - výsledky optimalizovaného kódu (ideálně profilovaného) jsou překvapivě dobré a zároveň si ušetříte spoustu práce.

2Eagle: Co na to rict... Nemate paru, co je to optimalizace. Ja pisu specialni verze kodu pro kazdou architekturu (3 verze P6, 2 verze K7, 2 verze K8, 2 verze P4, ...), aby dosazeny vypocetni vykon byl blizky peak flops (tedy napr. 8 GFlops pro K8). Realne cislo v praxi je casto bohuzel jen 1/3 teto hodnoty, jelikoz neni misto v registrech a musi se proto pouzivat RAM (cache). A kdyz instrukce cte/zapisuje z/do RAM (cache), CPU -MUSI- tuto operaci uskutecnit. Bez ohledu na to, kolik ma uvnitr virtualnich registru. Pokud je mozne drzet data v registrech, stoupne vykon 3x. Stejne je to s prokladanim instrukci. Kazde CPU potrebuje jinak prokladane instrukce. Conroe jeste neznam, ale treba K8 si samo nedokaze preusporadat SSE instrukce uplne optimalne. BTW: Optimalizovany C++ kod je v mem pripade zhruba 6x pomalejsi, nez rucne optimalizovany ASM (SSE) kod...

2xR: Zápisy do RAM se dnes dělají zpožděně. To si fakt myslíte, že CPU bude čekat stovky cyklů, než se tam ta data zapíší? Co se zápisů do cache týče, tam asi je možné něco ztratit. Ani to ale nemusí být nutně v daném pořadí. Zřejmě vám vzniká store-load závislost.
Jaký kompilátor byl použit a s jakým nastavením?

2Eagle: Nikdo nemluvi o stovkach cyklu. Tady jde o 6 cyklu za load/store instrukci. Pokud mam napr. sekvenci load-compute-save, dela to minimalne 6-4-6 taktu. Kdyby data bylo mozne mit stale v registrech, byly by to pouze 4 takty. Teoreticke zrychleni 4x...

Pokud jeste zapocitam pipelining, efektivni doba trvani se zmeni z 6-4-6 na 1-1-1. Zrychleni po odstraneni load/store operaci je porad 3x.

2xR: Dobře, tohle se dá uznat (pokud CPU nebude schopné dělat zápisy a čtení zpožděně a zajistit si integritu dat). Nicméně je to přeci jenom dost specifický příklad, u standardních high-level kompilovaných kódů se toho asi moc nezmění. A u této většiny programů asi bohužel žádné zrychlení nenastane. Leda že by se kompilátory přizpůsobily natolik, že budou více registrů využívat naplno.