A Power6 és a Cell révén folytatódhat az órajel verseny
Oldal 1 / 2Következő →
Jelentkezz be a hozzászóláshoz.
#54
Mégiscsak szerepelt: http://news.spong.com/article/11413?cb=369
#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).
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).
#51
Kiváncsi leszek mikor publikálnak(ha egyáltalan valaha is) SPECint/SPECfp értékeket.
#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.
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.
#49
Továbbá van egy ilyen is: IBM XL C/C++ compiler, ami még inkább Cellre "hangolt".
#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.
#47
(Jobb esetben.)
#46
Hol? A GPU-k is SP-ben csinálnak mindent (T&L, vertex- és pixelshaderek, dx10-ben geometria is).
#45
"Hova kellene ez egy játékban?"
Sokszor a single precision miatti kerekítési hiba kényelmetlen.
Sokszor a single precision miatti kerekítési hiba kényelmetlen.
#44
"csak azok nem fejlesztenek" -> na jó: fõleg azok nem fejlesztenek
#43
Hova kellene ez egy játékban?
#42
Ehh, kimaradt egy /.
#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?
[i]"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.
"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.
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?
[i]"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.
"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.
#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.
Nem tudom mit értessz bugyutább alatt. Mi elég komoly játékokat fejlesztünk, mégse használunk double-t.
#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.
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.
#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.
"Á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.
#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."
http://en.wikipedia.org/wiki/SSE4
"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."
http://en.wikipedia.org/wiki/SSE4
#36
Na, ennek majd késõbb még jobban utánanézek, mi is van.
#35
(Sok helyen tévesen az SSSE3-at
#34
Rosszul tudod. SSSE3 van. SSE4 majd a köv. gen.-ben lesz.
#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.
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.
SSE3 nem az utsó P4-ekben volt? Úgytudom a C2D-ben SSE4-van.
Vain ei kuulu terroristien käsiin! CS. N. T. K. K.! SG az a hely ahol sunyi módon csöndben törölgetik a hozzászólásokat, indok nélkül. ;)
#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.
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.
#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.
#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).
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).
#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 <#vigyor0>)
#27
Szerencsére semmi. :-)
#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.
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.
#25
Nálad jobban, prüntyõke :D
#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.
"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.
#23
"megfelelõ fordítóval megfelel egy átlagos 3.2GHz-es procinak" -> mármint a PPE-je
#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.)
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.
Nyomhatja akármiben, ha egyszer eszi az erõforrást.
Amiga 1200 030/882/40, 32MB Playstation 2, Playstation 3 AMD Athlon 64 X2 [email protected], 2GB DRR2/800, Sapphire HD4830@780Mhz 512MB, BENQ G2400W TFT
#20
Te már csak tudod pubi... :))))))
Amiga 1200 030/882/40, 32MB Playstation 2, Playstation 3 AMD Athlon 64 X2 [email protected], 2GB DRR2/800, Sapphire HD4830@780Mhz 512MB, BENQ G2400W TFT
#19
Ööö, a Mac OSX nem HW OpenGL-bõl nyomja a csicsát?
#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 :)
Igaz, de szerencsére semmi köze a Netburst-höz ezeknek :)
#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.
2. A cell egy elba*ott architechtúra, általános feladatokra lassú, amire pedig készült arra meg idõigényes optimalizálni.
#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.
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.
Amiga 1200 030/882/40, 32MB Playstation 2, Playstation 3 AMD Athlon 64 X2 [email protected], 2GB DRR2/800, Sapphire HD4830@780Mhz 512MB, BENQ G2400W TFT
#14
Állítólag azért váltottak, mert az IBM elhanyagolta a hordozható gépekbe szánt chipeket. Az intel röhögött és fél éve talán bemutatta a jobb teljesítményû és kevesebb fogyasztású mobil procijait.
Amiga 1200 030/882/40, 32MB Playstation 2, Playstation 3 AMD Athlon 64 X2 [email protected], 2GB DRR2/800, Sapphire HD4830@780Mhz 512MB, BENQ G2400W TFT
#13
Mac-ban csomó erõforrás elmegy a felhasználói felület csicsáira, 3d effektjeire, van a cégnél duál magos mac laptop, röhögünk mikor projectoron megy róla valami, alul néha fullra kiakad a 2 terhelésjelzõ csík. Háttérben megy flash html, akármi, akkor is szépen terhelõdik.
Cell pont erre lenne jó benne, hogy nem a fõmagot terhelik ezek a f*szságok.
Cell pont erre lenne jó benne, hogy nem a fõmagot terhelik ezek a f*szságok.
Amiga 1200 030/882/40, 32MB Playstation 2, Playstation 3 AMD Athlon 64 X2 [email protected], 2GB DRR2/800, Sapphire HD4830@780Mhz 512MB, BENQ G2400W TFT
#12
Hiába dalolsz, akkor is megszívta. Az intel architektúrában nem tudják tovább növelni a teljesítményt az órajel növeléssel, mert szétég a szilícium, beleb*sznak több magot - zsákutca megint csak.
Amiga 1200 030/882/40, 32MB Playstation 2, Playstation 3 AMD Athlon 64 X2 [email protected], 2GB DRR2/800, Sapphire HD4830@780Mhz 512MB, BENQ G2400W TFT
#11
"Eszerint 2012-re elérhetõvé válik a 22 nanométeres csíkszélesség, és az akkor megjelenõ chipek 48 MB-os gyorsítótárral, 4 milliárd tranzisztorral, valamint 100 wattos fogyasztással érkeznek majd" - idézve innen
phú, hát ez jól hangzik, de hiszem ha látom mûködni :)
phú, hát ez jól hangzik, de hiszem ha látom mûködni :)
#10
mellesleg télleg kár volt váltani az applenek vagyis sztem kéne mellete párhuzamosan fejleszteni az IBM.es gépeket is.
#8
Tényleg nem szerepel, de érdekes lenne, ha nem beszélnének róla. Maga az infó a "next gen." Cellrõl hivatalos egyébként. (Linket most nem tudok.)
#7
Na ez az, amit mát tényleg nem lehet túl sok helyen alkalmazni.
(Hihi, átjavították 8-ra, pedig tényleg 80. :) )
Egyébként a 4-magos Opteron, amit az AMD mutat be, minden valószínûség szerint már K8L alapú! Talán ez sem teljesen mellékes.
(Hihi, átjavították 8-ra, pedig tényleg 80. :) )
Egyébként a 4-magos Opteron, amit az AMD mutat be, minden valószínûség szerint már K8L alapú! Talán ez sem teljesen mellékes.
#6
Érdekes cím... :P Mintha x86 vonalon nem növekedne majd tovább a késõbbiekben az órajel... Csak nem úgy, mint a P4 esetében, hogy magasabb órajel, de mégis kevesebb utasítás (P3-hoz, K8-hoz, ill. most már a C2D 1-1 magjához képest).
#5
80 mag :O
Oldal 1 / 2Következő →