Vlákno názorů k článku AMD Opteron - 64bitový procesor nové generace od jura - ...proč ne, když AMD vždycky mluví o spolupráci...
-
Článek je starý, nové názory již nelze přidávat.
-
jura (neregistrovaný)
...proč ne, když AMD vždycky mluví o spolupráci s Transmetou, ale proč potom stále AMD vyrábý procesory s největším výkonem (hlavně tepelným). Linus se prý nechal na přelomu roku slyšet, že všechny ostatní platformy nemají proti ia32 výkonově šanci... fajn... AMD navázala. Proč ne! Itaniu se už přezdívá Itanic a pařani, kterých je nejvíc, by svoje W98(ME,SE ...wokna chytly už druhý dech) na Itaniu nenabootovali, takže bude zase jedno levné železo, co na tom, že bootuje v 16ti bitovém modu přes spoustu udělátek.
Co se týká ostatních platforem, možná jste si všimli, že mají opačný indián. Tady mám problém s terminologií, protože v nějakém starém manuálu k TMS340 (procesor, na kterém byl postavený standard TIGA) se psalo, že používá "little endian", protože číslo v paměti končí na LSB, zatímco intel používá "big endian". V současné době zase slýchávám, že ia32 je "little endian" architektura. At je to jakkoliv, já mu raději říkám "intel indián" a ten je k lidem, kteří nejsou při programování v C moc "opatrní" mnohem ohleduplnější, než ten opačný indián. Provoláte-li např knihovní funkci, která očekává int32_t parametr s int16_t argumentem, u intel indiána se většinou zázračně trefíte, zatímco u opačného indiána dostanete v lepším případě EINVAL, v horším to "nějak blbne", SIGSEGV nebo SIGBUSí.
To, že AMD64 zůstal u intel indiána považuju za největší výhodu. Bohužel asi jedinou. V každém případě bude nejspíš komerčně úspěšný a v konečném důsledku pozdrží, nebo potopí Itanic :->
Jinak sada univerzálních registrů je fajn, ale nevíte někdo náhodou, jak to podporuje gcc při optimalizaci? ;-)
Nevíte taky někdo, jak je to s provozní teplotou takového "parostroje"? Nepočítám s tím, že by to "topilo" jako můj celer, který má ted (po 14ti dnech bez vypnutí) +37.5 C na CPU s pasivním chladičem (CPU je původní Coppermine 850MHz přetaktovaná na 950MHz a FSB má "zvednuté" na 120MHz) a +52.5 C ve zdroji s jediným větrákem, luftujícím celou bednu, přepojeným z původních 12V na 5V. Zatím všechny ostatní AMD K7 sestavy jsem z garsonky lifroval pryč hned po zásazích, které jsem na nich provedl, protože nemám přílišný hluk rád.
Myslím, že výkonový zisk oproti P4 nebude nijak závratný, zvláště zapnete li "hyper threading", takže Intel bude zase léta vylepšovat P4, místo aby derivoval něco jako Celeron z Itania2... ach JO!!! At s tím krámem táhnou k čertu!!! -
_ (neregistrovaný)
Zas jeden chytrak, co mu AMD topi vic nez Intel? ;-) Maximalni spotreba u AMD CPUs je do 75W, top Opteron ma 80W, maximalka u P4 3GHz je ke 100W. Jake ze to CPU topi vic? A co takove Itanium? Hehe. Nejak si taky zapomel porovnat vykon toho svojeho frdlatka, s poradnym strojem od AMD, ;-) mno nic. Pokud mas problem postavit tichou, vykonnou sestavu s AMD CPU, problem hledej u sebe. Ses kus lamy...
-
jura (neregistrovaný)
Lam, které se neumí ani podepsat je na Netu dost a dost, takže dneska zase nepokecám s někým, kdo je schopen věcně argumentovat. Na druhou stranu jsem se dopustil drobných zjednodušení. Už tak jsem napsal moc písmen a kdybych měl všecko do detailu vysvětlit, bylo by to delší, než původní článek, který byl na můj vkus opravdu zjednodušující až příliš, takže doplním:
- jsem jeden z mála lidí, co používají počítač m.j. i na počítání (RT-simulace), takže moje zkušenosti nemůže aplikovat pařan, který má na počítač úplně jiné nároky. Zkusím to stručně nastínit. Problém je v FPU. Ta se dnes už skoro nevyvíjí, takže si Intel pořád zachovává svůj bývalý náskok. Bohužel FPU se nedá pro "opravdové" počítání nahradit žádným jiným "kusem železa" a gcc to ve výsledném kódu respektuje. Jako testovací nástroj používám FFT algoritmus (slovo benchmark šetřím pro opravdové lamy, co měří čísla a ne skutečné parametry ;-). FFT algoritmus totiž poskytne nejen představu o rychlosti, ale i o velikosti kumulovaných chyb během výpočtu. Platí totiž A=FFT(FFT(A)) kde A je vektor (jednorozměrné pole) komplexních čísel. Pokud za A dosadím pouze reálnou posloupnost, pak se mi po provedení FFT a /FFT v Im(A) (imaginární složka A) nakumulují chyby výpočetních operací. IEEE norma pro výpočty v plovoucí čárce totiž definuje nejen formáty zpracovávaných čísel, ale i metody zaokrouhlování, aby se statisticky potlačily právě tyto kumulované chyby. Když jsem tento test zkoušel překládat M$-C, které přímo hýří optimalizacemi pro K7, C překladač začal vytvářet kód používající 3DNow instrukce, které sice počítaly 2 až 3násobě rychleji, ale kumul. chyby vzrostly až 10E+8 krát!!!! Po čase se mi pak jeden jeden stavební statik svěřil s problémem, že přechodem na novější verzi AutoCADu jim některé moduly knihovny začaly dávat až 20-30%ní roptyl vypočtených hodnot. Takže asi nebudu jediný, kdo se s tímto problémem potkal.
- IA vychází v dávné historii z původní 8086, která nebyla navržena pro běh více úloh současně (několik specializovaných registrů místo pole GP registrů, časově náročné přerušení, ....), což je základní předpoklad pro RT (reálný čas). Navíc tato orientace u nás byla stanovena závěru sjezdu KSC (jeho číslo si nepamatuju) jako "jediná správná", takže odmítaní procesorů Intel mělo u naší generace věcný podklad a vyústila až ve známé Intel Outside. Toto ale bylo s odstupem času asi špatně pochopeno mladšími a ti to nesprávně vztáhli na napodobovatele Intelu. Zatímco Intel měl už 20let na "zazáplatování" svých chyb, jeho napodobovatelé tyto chyby, zdá se, ještě asi ani nezaznamenali. A pokud někdo přidá pole GP registrů, podobné jako měla moje oblíbená m68k, nebude to pro mě mít význam, dokud jej nezačne gcc podporovat.
- co se týká výkonu mého desktopu, Tak mohu z vlastní zkušenosti říct, že CPU se na něm moc nepodílí. Rozhodující je spíš velikost paměti, mám rád moc virtuálních desktopů a každý člen domácnosti má "svoji mozillu" trvale na některém z nich. Když k tomu připočtu několik rozepsaných dokumentů ve StarOffice a "všude zalepeno terminálama", v tomto případě se na výkonu podepíše jak moc se swapuje, než cokoliv jiného. Byl tady v diskusi odkaz ma Tom's HW s testy rychlosti Opteronu v jednotlivých oblastech. Zklamalo mě, že se zde nesrovnával i Linux desktop, protože na encodování filmů používám mencoder. Na popsaném stroji empiricky dosahuji časů jen o maličko lepších než K7 Athlon na 1.2GHz (viz. výkonnější FPU).
No a aby mě někdo nepodezíral, že přece jen někde v koutku stranním Intelu, uvedu seznam věcí, které jsou u intelu výrazně horší. Uvedu jen jednotlivosti, které mám otestované. Na současném stavu mi totiž právě vadí to, že se setkávám s názory týpků, kteří, snad aby je svět uznal za hackery, zobecnují nezobecnitelné:
- pokud někdo požaduje "opravdový" výpočetní výkon, pak se musí obrátit úplně jinam, než k wintel platformám. Jedem můj bývalý kolega, když ještě nebyl mým kolegou, dělal správce IRIXu na blíže nespecifikovaném Onyxu. Během týdne se ocitl na čelní pozici seti@home u nás, když na tomto 64xCPU kousku spustil klienta tohoto projektu ;-)
- Pokud děláte RT aplikace a zajímá vás rychlost, s jakou je CPU schopna přepínatúlohy, tak tady má navrch zase Ultra SPARC platforma. Pole GP registrů o velikosti nekolika 10-100kregistrů vás totiž nenutí odkládat pracovní registry na zásobník, ale stačí poposunout bázový ukazatel do pole registrů, takže výsledný EIRT "čas odezvy na vnější přerušení" vám prostě vyrazí dech ;-)
- jestli chcete pařit a pařit, pak jásejte! AMD jsem totiž nenazval CPU pro pařany náhodou. 3DNow je ve své cenové kategorii nejvýkonnější 3D akcelerace a "poněkud vyšší" tepelný výkon AMD K7 je ve srovnání s takovým GeForce-FX zcela zanedbatelný.
No a pokud někoho irituje název mého příspěvku, tak to není nic proti tomu, jak mě nadzvedl zmíněný Torvaldsův výrok, pronesený odněkud z jachty v karibiku a Linuse omlouvá jen pravděpodobně velmi uvolněná atmosféra, ve které se zrodil :-))) a konec konců jako jeden z "nejstarších" tučnáků u nás mám na svoje "stařecké vrtochy" i tak trochu nárok :-)))))))))))
