dez#52"Pedig korrekt, a G5-re se volt optimalizálva: a debugos kódhoz képest az optimalizált kód 5%-ot sem gyorsul."
Na de értsd már meg, hogy a G5 out-of-orderes, rendes branch-prediction van benne, stb. Így ezek tekintetében nem kell külön optimizálni, azaz sokkal jobban tud alkalmazkodni az "egyszeri" kódhoz is, mint a PPU. Ezért ugyanazt a kódot ráengedni a PPU-ra különös kegyetlenség, kiszúrás. :D Ami helytakarékosságból ki van belőle tranyó szinten spórolva, fordító szinten kell amennyire csak lehet pótolni. Ez eleve így van kitalálva.
"Az általános esetek azok amelyek minden programban szerepelnek.
pl. a kernel hol használ SIMD egységet vagy egy kereső stb?"
Jaj, ne csináld már. Most az, hogy nem minden programnak van rá szüksége... De pl. minden normális, hétköznapi médiafeldolgozó, lejátszó program SIMD-es. Meg még jópár másik is. Jó, nem ez a legáltalánosabb eset, de nem is annyira speciális. Szóval az általános integer teljesítmény mellett ez is fontos adat. És ebben a PPU-ban lévő VMX azonos órajelen is jóval gyorsabb lehet, mint a P3-ban lévő SSE.
"Te tévedsz :)"
Ha én, akkor velem együtt még nagyon sokan...
"16 bites FP-t, csak néhány célprocesszor használt pl. Nvidia FX sorozat.
A 16 bites FP egyszerűen használhatatlan, még a 32 bites integer is lényegesen jobb."
Jaj. Csak annyira használhatatlan, hogy az IEEE szabványban is benne van (IEEE 754).
Half-precision floats are used in cases where neither the range nor the precision of 32 bit floating point numbers are needed, but where some dynamic precision is required. Two common uses are for image transformation, where the range of each component (e.g. red, green, blue, alpha) is typically limited to or near [0.0,1.0] or vertex data (e.g. position, texture coordinates, color values, etc.).
The main advantage of half-precision floats is their size. Beyond the considerable potential for memory savings, processing a large number of half-precision values is more cache-friendly than using 32 bit values.
(link)
"Nyílván ezért erőltetik a Power sorozatban a 64 bites FP-t, mert elég a 32 is.
Nem azt mondtam, hogy mindenre elég.
"Szerinted miért nem csak cellből építik? Ugyanannyi opteron lesz benne, mint cell."
Visszakérdezek: minek használnak szerinted ott Cellt egyátalán? Miért nincs azok helyett is Opteron? Jobban megérné, ha csak a DP-ből indulunk ki.
"Fognak fejleszteni PS3-ra ez nem kérdes, de a megtérülés már problémás lesz. Az EA-nak nyílván nem gond, ha 10 projektből 5 bukás, a másik 5 finanszírozza, de a kisebb cégek(ami magyar szinten akár sok milliárd ft forgalmút is jelenthet), egy egy játékba bele is bukhatnak."
Jahh, hát nagy fához nagy fejsze kell. De a faanyag is annyival több lesz. :)
"Aha, persze."
Nem én találtam ki, hanem Mike Acton (Highmoon Studios). Goto cellperformance.org.
"Arról még nem is beszéltünk, hogy általános számítógépes felhasználásra már csak azért is alkalmatlan a cell, mert egyszerre 10+ program is futhat, melyek hiába optimalizáltak szarrá külön-külön, együtt pont kiütik egymást, azaz nem 10-edére csökken a teljesítményük, hanem lényegesen rosszabb lesz."
Miért is lesz ebben annyival rosszabb a Cell, illetve a PPU, mint más procik? Főleg hogy a multithreadinget itt HW SMT támogatás is segíti.
"Erre még egy egyszerűbb hw esetén is van jó pár példa, P4 esetén a HT sok programnál érdemes volt kikapcsolni, mert egy-egy közbe iktatott más thread annyira megborította, hogy drámaian esett a teljesítmény."
Drámai esésről nem tudok, csak pár %-ról (1 fő szál esetén), mert ugye a háttérprocessek folyamatosabban futottak, foglalva a proci "erőforrásait", szakaszosság helyett. 2 fő szál esetén viszont hozta a formáját (közelítette az 50-50%-ot, azaz beérte az Athlonok hasonló körülmények között mutatott teljesítményét :P).