54
-
dez #54 Mégiscsak szerepelt: -
dez #53 Azzal még nem nagyon találkoztam, de van LinPack, meg jópár más: link -
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). -
Power #51 Kiváncsi leszek mikor publikálnak(ha egyáltalan valaha is) SPECint/SPECfp értékeket. -
Power #50 "Valós, de nem korrekt, mert egyátalán nem optimizál a PPE-re. Ha optimizálna, valószínű kicsit mások lennének az arányok."
Pedig korrekt, a G5-re se volt optimalizálva: a debugos kódhoz képest az optimalizált kód 5%-ot sem gyorsul.
"Nagyon is hozzátartozik ez is, mivel sok program alkalmazza a SIMD egységet pl. x86-on is"
Az általános esetek azok amelyek minden programban szerepelnek.
pl. a kernel hol használ SIMD egységet vagy egy kereső stb?
"Ez tévedés. A bugyutább, sőt nem is olyan bugyuta játékokhoz még a 16 bites FP is elég. Lásd újfent cellperformance.com
2 éve írtam egy feedbacket IBM-éknek a Cell DP vs. SP teljesítményéről, azt válaszolták, sok tudományos alkalmazáshoz elég az SP is. Tudsz róla, hogy Cellekből és Opteronokból most épít szuperszámítógépet?"
Te tévedsz :)
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.
2 éve írtam egy feedbacket IBM-éknek a Cell DP vs. SP teljesítményéről, azt válaszolták, sok tudományos alkalmazáshoz elég az SP is. Tudsz róla, hogy Cellekből és Opteronokból most épít szuperszámítógépet?
Nyílván ezért erőltetik a Power sorozatban a 64 bites FP-t, mert elég a 32 is.
Szerinted miért nem csak cellből építik? Ugyanannyi opteron lesz benne, mint cell.
"Abban még nem, de 10-esben igen. Ha minden úgy lenne a Cellel kapcsolatban, mint egyesek mondják, egészen pontosan 0 csoport fejlesztene PS3-ra. Ezzel szemben csak azok nem fejlesztenek, akik a lehető legkisebb ráfordítással akarnak üzletet csinálni. Szerencsére nem mindenki így gondolkodik."
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.
"Nem feltétlenül lesz ebben nagy változás. Leginkább az elején kell kitalálni a megfelelő adatformátumokat, adatkezelési útvonalakat, stb"
Aha, persze.
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.
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.
-
dez #49 Továbbá van egy ilyen is: IBM XL C/C++ compiler, ami még inkább Cellre "hangolt". -
dez #48 Egyébként most olvastam a Cell SDK doksijában, hogy a mellékelt GCC nem az eredeti, hanem saját fejlesztés (és itt nem csak az SPU-s extensionokra gondolnak). Na hát ezzel kellene fordítgatni dolgokat, és utána méricskélni. -
dez #47 (Jobb esetben.) -
dez #46 Hol? A GPU-k is SP-ben csinálnak mindent (T&L, vertex- és pixelshaderek, dx10-ben geometria is). -
BiroAndras #45 "Hova kellene ez egy játékban?"
Sokszor a single precision miatti kerekítési hiba kényelmetlen. -
dez #44 "csak azok nem fejlesztenek" -> na jó: főleg azok nem fejlesztenek -
dez #43 Hova kellene ez egy játékban? -
dez #42 Ehh, kimaradt egy /. -
dez #41 "A G5 is GCC, úgyhogy az eredmény valós."
Valós, de nem korrekt, mert egyátalán nem optimizál a PPE-re. Ha optimizálna, valószínű kicsit mások lennének az arányok.
"Mivel pontosan arról van szó, hogy általános esetben mire képes ezért ez a lényeg."
Nagyon is hozzátartozik ez is, mivel sok program alkalmazza a SIMD egységet pl. x86-on is (média enkóderek, dekóderek, stb. stb.). Ha letiltjuk, sokkal lassabbak lesznek. (A P3-800-as "esetet" is így kell nézni.)
"1. Speciális esetben"
Az ilyen "speciális esetek" ma már mindennaposak (multimédia, renderelés, stb.).
"2. Egy frászt nem, legfeljebb a bugyutább játékokhoz nem kell."
Ez tévedés. A bugyutább, sőt nem is olyan bugyuta játékokhoz még a 16 bites FP is elég. Lásd újfent cellperformance.com
2 éve írtam egy feedbacket IBM-éknek a Cell DP vs. SP teljesítményéről, azt válaszolták, sok tudományos alkalmazáshoz elég az SP is. Tudsz róla, hogy Cellekből és Opteronokból most épít szuperszámítógépet?
"Vettél már részt 50+ emberéves fejlesztésben?"[i]
Abban még nem, de 10-esben igen. Ha minden úgy lenne a Cellel kapcsolatban, mint egyesek mondják, egészen pontosan 0 csoport fejlesztene PS3-ra. Ezzel szemben csak azok nem fejlesztenek, akik a lehető legkisebb ráfordítással akarnak üzletet csinálni. Szerencsére nem mindenki így gondolkodik.
[i]"Mi? Egy szóval sem említettem az RSX-et."
Én említettem, mert azzal volt, hogy többször módosult a spec. Cell esetén csak az órajel némi csökkentése merült fel állítólag (de inkább csak egy újságírói félreértés volt), de nem következett be.
"Az emberek közötti kommunikációs igényre gondolok."
Nem feltétlenül lesz ebben nagy változás. Leginkább az elején kell kitalálni a megfelelő adatformátumokat, adatkezelési útvonalakat, stb. -
BiroAndras #40 "Egy frászt nem, legfeljebb a bugyutább játékokhoz nem kell."
Nem tudom mit értessz bugyutább alatt. Mi elég komoly játékokat fejlesztünk, mégse használunk double-t. -
BiroAndras #39 "Kit érdekel a dupla precizitás itt? Tudományos téren sem kell mindenhez."
Igazából kellene sokmindnehez, csak kerülik ahol lehet, mert lassú. Játékoknál meg azért is kerülik, mert nem minden platformon van egyáltalán. -
Power #38 A G5 is GCC, úgyhogy az eredmény valós.
"Általános teljesítményben nem is, de a VMX közel áll az abban lévő 128 bites SSE3-hoz"
Mivel pontosan arról van szó, hogy általános esetben mire képes ezért ez a lényeg.
"1. Hagyjuk már ezt az "elméletileg kihozható teljesítményt". Az IBM már régen bizonyította, hogy akár 95% is kihozható.
2. Kit érdekel a dupla precizitás itt? Tudományos téren sem kell mindenhez."
1. Speciális esetben
2. Egy frászt nem, legfeljebb a bugyutább játékokhoz nem kell.
"Nem csak elméletben. Ajánlom figyelmedbe a cellperformance.com lapot."
Vettél már részt 50+ emberéves fejlesztésben?
"Ne keverd az RSX-szel."
Mi? Egy szóval sem említettem az RSX-et.
"Persze, hogy bonyolultabb a tervezés, épp ezért kell jobban odafigyelni. Milyen kommunikációról beszélsz? A magok között talán? Az egyátalán nem szükségszerű, attól függ, milyen metódusban használod a Cellt. A SPE-k működhetnek teljesen önállóan is."
Az emberek közötti kommunikációs igényre gondolok. -
dez #37 "SSE4, also known as Nehalem New Instructions (NNI), is a new instruction set for the Intel Nehalem microarchitecture, which is slated to be released in 2008"
"What is now known as Supplemental Streaming SIMD Extension 3 (SSSE3) was also referred to as SSE4 by fans during development of the Intel Core microarchitecture. This has caused a bit of confusion in the community. Vendors such as NewEgg have mistakenly marked some of the Core 2 processors as having SSE4, when they actually have SSSE3."
-
dez #36 Na, ennek majd később még jobban utánanézek, mi is van. -
dez #35 (Sok helyen tévesen az SSSE3-at [direkt van 3db "S", tehát bővített SSE3] SSE4-nek írják. Legalábbis ezt oldastam több helyen.) -
dez #34 Rosszul tudod. SSSE3 van. SSE4 majd a köv. gen.-ben lesz. -
dez #33 "Ha csak a PPE-t használják arra van kiérlelt fordító, de az önmagában édes kevés: PS3 vs G5/1.6"
Nem hinném, hogy ez PPE-hez kiérlelt fordítóval jött ki. A GCC, ha arról beszélsz, még G3-4-5-höz sem túl jó kódot generál, hátmég a nagyrészt in-orderes PPE-hez, aminél főleg nagyon sokat számít a jó optimizálás.
"Egy C2D-vel nem is lehet összehasonlítani."
Általános teljesítményben nem is, de a VMX közel áll az abban lévő 128 bites SSE3-hoz.
"Továbbá double precizitás esetén még az elméletileg kihozható teljesítmény is nagyságrenddel gyengül."
1. Hagyjuk már ezt az "elméletileg kihozható teljesítményt". Az IBM már régen bizonyította, hogy akár 95% is kihozható.
2. Kit érdekel a dupla precizitás itt? Tudományos téren sem kell mindenhez.
"Az X360-on mind 3 mag eléri a memóriát, a cellnél pedig az SPE-k nem."
Az SPE-k is elérik (DMA-val), csak közvetlenül címezni nem tudják.
"2 év alatt sem jutottak sokra."
Kik?
"Ami a programozást illeti elméletben szépen hangzik, hogy okos tervezés + egyszerű lekódolás"
Nem csak elméletben. Ajánlom figyelmedbe a cellperformance.com lapot.
"de a gyakorlat az, hogy a "specifikáció" változik még a kódolás alatt"
Ne keverd az RSX-szel.
"és a tervezés bonyolultabb a cellen. emiatt mégt a kommunikációra is több idő fog elmenni."
Persze, hogy bonyolultabb a tervezés, épp ezért kell jobban odafigyelni. Milyen kommunikációról beszélsz? A magok között talán? Az egyátalán nem szükségszerű, attól függ, milyen metódusban használod a Cellt. A SPE-k működhetnek teljesen önállóan is. -
#32
"Melyik Celeronban van HW SMT? Vagy a C2D (S)SSE3 egységénél is jobb"
SSE3 nem az utsó P4-ekben volt? Úgytudom a C2D-ben SSE4-van. -
Power #31 Ha csak a PPE-t használják arra van kiérlelt fordító, de az önmagában édes kevés: PS3 vs G5/1.6
Egy C2D-vel nem is lehet összehasonlítani.
Továbbá double precizitás esetén még az elméletileg kihozható teljesítmény is nagyságrenddel gyengül. Az X360-on mind 3 mag eléri a memóriát, a cellnél pedig az SPE-k nem.
2 év alatt sem jutottak sokra.
Ami a programozást illeti elméletben szépen hangzik, hogy okos tervezés + egyszerű lekódolás, de a gyakorlat az, hogy a "specifikáció" változik még a kódolás alatt és a tervezés bonyolultabb a cellen. emiatt mégt a kommunikációra is több idő fog elmenni. -
dez #30 Ja, a "drámai" fejlesztési idő-növekedés: több játékfejlesztő cég már a legelső doksik megjelenése óta (2 éve?) ráállított komoly szakikat a Cell tanulmányozására. Az egyik Mike Acton, aki egy weboldalt is létrehozott arra, hogy lehet a leghatékonyabban és leggyorsabban fejleszeni Cellre. Az okos előzetes tervezésen múlik inkább a dolog, a leprogramozás nem olyan nehéz. -
dez #29 Melyik Celeronban van HW SMT? Vagy a C2D (S)SSE3 egységénél is jobb, és (SMT-re szintén felkészített) SIMD egység?
Ami az általános műveleteket illeti, nem lehet így összehasonlítani, teljesen más architektúra a kettő. A nagyrészt in-order (de memória-hozzáférési műveletek esetén out-of-ordert is tudó) végrehajtás miatt az optimizálatlan kód nem túl jól, az optimizált viszont elég jól fut rajta.
A fordítót az SPE-k miatt heggesztik, azt a részt addig is lehet kézzel optimizálni (nem feltétlenül asm-ben, de akár abban is, nem nagy ügy az sem, jól átlátható a kódja). De úgy tudom, volt már in-orderes procija az IBM-nek, kellene lennie erre optimizáló fordítónak. Ha esetleg nincs, az xbox miatt is össze kell hozni, mivel annak procija lényegében 3db PPE (kb. 1db utasítás-kiterjesztéssel). -
lee56 #28 Hmm akkor ps3 valóban nem nyerő. "Fi"xbox-ban milyen procika is van? (nem mintha vennék valaha, csak az a fránya kiváncsiság 
)
-
Power #27 Szerencsére semmi. :-) -
Power #26 Milyen 3.2-es procinak felelne meg? - egy celeronnak.
A megfelelő fordítót meg 1,5 évig heggesztik majd, addigra meg már azzal együtt is kevés lesz. Nem beszélve arról, hogy a programok fejlesztési ideje is drámaian megnő. Elég lesz megfigyelni mikorra lesz olyan ps3 játék ami hatékonyan kihasználja majd a cell-t, pedig ott az egész hw fix, egy pcnél meg úgye messze nem lehet erre alapozni. -
Power #25 Nálad jobban, prüntyőke :D -
dez #24 a pontosság kedvéért ezt is:
"Kb. mint egy 8 magos, magonként 1-1 SIMD egységet tartalmazó procira." -> akarom mondani, 9 magos, mert a PPE-ben is van egy AltiVec/VMX egység, ráadásul SMP-re felkészített az is, mint az egész PPE. -
dez #23 "megfelelő fordítóval megfelel egy átlagos 3.2GHz-es procinak" -> mármint a PPE-je -
dez #22 "A cell egy elba*ott architechtúra, általános feladatokra lassú"
Hülyeség. Esetleg a mostani Cell chipre mondhatnád ezt, az architektúra úgy van kialakítva, hogy több PPE is lehet benne, és lesz is ilyen Cell változat. Ami meg a mostani 1 PPE-s Cellt illeti: megfelelő fordítóval megfelel egy átlagos 3.2GHz-es procinak, és mivel sok feladatot levehetnek a válláról az SPE-k, eleve kevesebb dolga lehet.
"amire pedig készült arra meg időigényes optimalizálni."
Kb. mint egy 8 magos, magonként 1-1 SIMD egységet tartalmazó procira. Jahh, hogy ilyen desktopon nem létezik másik...
Lefordítva mindezt MAC-re: az OS és a programok alapfunkciói bőven elmennének a PPE-n, és a számításigényes dolgokat át lehetne vinni az SPE-kre. (Alig kellene átírni a korábban meglévő AltiVeces kódokat, lévén nagyjából azt az utasításkészletet használja, plusz a szokásos PPC utasítások.) -
#21
Azt tudom, hogy akkor is beszaggatott, amikor csak 512 mega volt a gépben.
Nyomhatja akármiben, ha egyszer eszi az erőforrást. -
#20
Te már csak tudod pubi... :)))))) -
Inquisitor #19 Ööö, a Mac OSX nem HW OpenGL-ből nyomja a csicsát? -
Inquisitor #18 "A netburst a zsákutca, de jelenleg az intel gyártja a legerősebb asztali és mobil processzorokat"
Igaz, de szerencsére semmi köze a Netburst-höz ezeknek :) -
Power #17 1. Nem hencegnék azzal, hogy egy cégnél nem képesek egy számítógépet normálisan beállítani.
2. A cell egy elba*ott architechtúra, általános feladatokra lassú, amire pedig készült arra meg időigényes optimalizálni. -
Power #16 Egy frászt.
Teljesen jól csinálta. Az eladások megugrása is ezt bizonyította.
A netburst a zsákutca, de jelenleg az intel gyártja a legerősebb asztali és mobil processzorokat és ebben csak az amd fogja(?) majd szorongatni. -
#15
Intel f*szt. IBM. Reggel van még, eh.