Új hozzászólás Aktív témák

• #8 dezz nagyúr bit_vector #3

  Új Válasz 2007-03-18 00:10:34 #8

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz bit_vector #3 üzenetére

  ''ahova ténylegesen nagy számítási kapacitás kell, oda nem cell-t fognak rakni''
  
  Nem? Pedig pl. az IBM a következő szuperszámítógépét 50%-ban Cellből építi.
  
  ''hanem a számítási feladathoz illő processzort...''
  
  És ez mi is lenne? Gyorsan fejlesztenek egyet pártízmillió dollárból? ;) Nem véletlenül terjed pl. a GPU-k általánosabb számításokban való felhasználása. Még mindig gazdaságosabb azokkal szenvedni, mint új procikat fejleszteni. A Cellel meg ehhez képest jóval könnyebb a munka, plusz azonos elméleti FLOPS-ból többszörös teljesítmény hozható ki vele. Ja, és nem csak stream-feldolgozásra alkalmas.
  
  Igaz, nem nagyon szereti a Cell a feltételes ugrásokat, de ez inkább csak a sima CPU-magja (PPE) számára jelent gondot (ami megfelelő optimizációval, ill. constraintekkel csökkenthető). A vektorproci-magok (SPE-k) mindegyike saját, L1 cache sebességű 256KB-os embeddedrammal rendelkezik, onnan futnak a programok és ott vannak az éppen felhasznált adatok, így nem jelentkezik az a durva késlekedés, mint amikor egy szokásos procinak a lassú főmemóriából kell újratöltenie magát egy-egy rossz elágazásbecslés után.
  
  robyeger: a napokban közölte az AMD, hogy közösen az IBM-mel nekik is sikerült előállítani az első működő 45nm-es procit. (Bár ez még csak egy kísérleti chip volt, nem valami újabb generációs K-akármennyi.)
  
  [Szerkesztve]

• #10 dezz nagyúr bit_vector #9

  Új Válasz 2007-03-19 00:55:32 #10

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz bit_vector #9 üzenetére

  ''Na persze, kell a reklám neki, mert még új. Arra gondoltál már, hogy miért nem mondjuk 99%-ban van benne Cell ?''
  Ugyan, ez egy kicsit drága reklám lenne.
  Gondoltam: valami kell a (ha jól emlékszem) 32000db Cell közötti kommunikáció biztosítására is. Másrészt persze általános feladatokban is ütősnek kell lennie, nem csak számításokban.
  
  ''- Ha megfizetsz egy normális és jó mérnököt, kb. egymillióból is kihoz neked a feladatra alkalmas processzormagot.''
  Kötve hiszem. Vettem már részt kb. ilyen nagyságrendű (dollárban) hw fejlesztésben, enyhén szólva nem fért bele ilyesmi, csak 1-2 FPGA felprogramozása, amiben persze lehet mikroproci, de csak egyszerűbb. A Cell kifejlesztése állítólag többszáz millió dollár volt (mérnökcsoport többéves munkája, próbagyártások, stb.).
  
  ''- legtöbb esetben az irányító feladatot ellátó processzor mag van a feltételes elágazásokra kihegyezve. Teszik ezt azért mert legtöbb esetben ő hajtja végre a feladatszálak párhuzamosítását.''
  Feladatszálak párhuzamosítását? Ezen mit értesz? Real-time A.I.-s párhuzamosító? ;)
  (Fejleszt egyébként az IBM egy ilyen spéci fordítót Cellhez.)
  Viccet félre téve, bizonyára a párhuzamos szálak összehangolására, megfelelő időben való indítására, stb. gondolsz. Nos, lehet így is csinálni, de teljesen önállóan is működhetnek az SPE-k, egymást vezérelve is (egymás memóriáját is látják). A kódot és az adatokat maguk töltik/mentik a főramból saját DMA-val.
  
  ''- 256kB EmbeddedRAM pedig lufira sem elég. Főleg, hogy egyes algoritmusok adatigénye ettől jóval nagyobb''
  Hát ja, bizonyos dolgokra nem elég. Sok más dologra meg igen. Léteznek ám Cellhez hasonló, de sokkal szerényebb DSP chipek jópár éve, elég sokmindenre használják őket. Hozzájuk képest a Cell egy monstrum.
  
  ''(hozzávetőlegesen: ha extrém nagy pontosságú pi-t számolsz, akkor adott esetben ez a 256kB-hoz képest a szám memóriaigénye akár sokszorosa is lehet - nem beszélve arrról, ha szeretnél vele számolni is)''
  Poénos extrém pontosságú pi-t számolni, de nem igazán hétköznapi tudományos feladat.
  Mellesleg nem kell az egész számsornak egy időben a belső memóriá(k)ban lennie.
  
  ''- maga az architektúra erősen korlátos... kicsit úgy hat, mint a Microchip gyártó Propeller mikrovezérlője.''
  Erős túlzás.
  
  ''- A számítási teljesítmény minden esetben stream alkalmazásoknál lesz a legnagyobb.''
  Nem feltétlenül. Attól függ, az adott streammel mit is kell csinálni...
  
  ''A miértre annyit, hogy ott lehet a leghosszabbra venni a pipeline méretét, ráadásul a stream mód miatt kevés lesz a feltételes elágazás benne (egy példa : digitális jelfeldolgozás).''
  Stream-feldolgozáshoz is kellhet sok-sok elágazás, feladattól függően.
  
  ''- Constraint? optimalizálás??? ember, ezek mind a fordító oldalon jelentkeznek, ha egy feltételes elágazást így veszek ki a programból, csak a kód mérete lesz nagyobb, sőt adott esetben lassabb is...''
  1. Bevett optimizálási gyakorlat az ugrások kivétele, és a ciklus ''letekerése''. Architektúrától függően sokat gyorsíthat. Pl. GPU-knál is gyakori.
  2. Az ide vonatkozó constrainttel azt mondod meg a fordítónak, melyik végrehajtási irány lesz a gyakoribb. Ez tehát nem veszi ki az ugrást.
  
  ''Programoztál már assembly-ben ? és hány processzorcsaládon ?''
  Nagyjából 20 éve ezt teszem, kisebb-nagyobb megszakításokkal. 65xx/85xx, 68k (fpu is), PowerPC (ezt csak keveset), különféle mikrokontrollerek.
  
  [Szerkesztve]

Új hozzászólás Aktív témák