dez#21
"Akkor olvass jobban utána, ha már ennyire magabiztosan állítasz valamit, vagy inkább kérdezz."
Szerintem kérdés nélkül is leírhatod, ha más irányú adatod van. (De kicsit konkrétabban, mint alább.)
""mert mindenhol lassabb a DP"
Ez sem igaz."
Oh, valóban, egy pillanatra megfeledkeztem róla, hogy pl. egyes procik eleve DP-ben, vagy extended prec.-ben nyomják (és ha SP számra van szükség, úgy kerekítik vissza). De azért a legtöbb helyen nem így megy.
"egy nagyságrenddel lassabb a cellen a dp peak."
Erről ellentétes adatokat láttam. Egyes helyeken 1/10 teljesítményt ír a IBM, máshol 1/4. De még ez sem nevezhető olyan lassúnak.
"2a). Nem most jöttem le a falvédőről ilyen marketing dumáknak én már nem dőlök be."
Ez nem marketing duma. Nem úgy olvastam, és itt csak továbbadtam, hanem van erről egy egész komplett prezentáció, ami valamelyik szakmai bemutatón hangzott el, nem laikusoknak.
"b). Ezek marketing demók, kihegyezve 1-1 rész területre, de egy valós alkalmazás ettől annyira távol van, mint az ég és a föld."
Hogy is mondtad? "Akkor olvass jobban utána, ha már ennyire magabiztosan állítasz valamit, vagy inkább kérdezz." Nos, ez nem egészen így van. Az igaz, hogy az egyik demó ugyebár mpeg2 dekódolás volt "kereskedelmi mennyiségben", de nem spéci kézzel optimizált ASM kód volt, hanem az SDK segítségével összerakott, C kódú programocska, ami szálainak megfelelő ütemezését a Cellhez fejlesztett OS alrendszer irányította (tulajdonképpen pont ez utóbbit demózták elsősorban, csak olyasmivel, ami a laikusok figyelmét is felkelti, és persze témábavágó - ezt a Toshiba tartotta egyébként, aki főleg ilyesmi célokra akarja használni).
A másik demó egy 3D render motor volt, ami már jóval kevésbé nevezhető olyan spéci dolognak, mint a videodekódolás.