Andrei#16
Tudnád esetleg bővebben indokolni a kijelentéseidet? (És tudnál esetleg kevésbé bántóan fogalmazni?)
Kerlek, menjunk sorban.
"Mit nevezel "nagyteljesitmenyu szamitasok"-nak?"
High performance computing (HPC). Olyan alkalmazasok, ahol a szamitasi teljesitmeny maximalizalasa elsodleges szempont. FEA, aramlastan, numerikus matek (elsosorban numerikus linearis algebra, diffegyenletek, optimalizacio), asztronomia.... A multimedia hatareset, nemely reszei idetartoznak.
"Itt mi a "más jellegű"?"
Pl. olyan szamitasok, ahol a 64bites lebegopontos szamitasokra van szukseg. A HPC alkalmazasok 90+%-a ilyen es a Cell teljesitmenye tizedere (in terms of FLOPS) esik vissza double precision hasznalata eseten.
Megaztan ott van a 256MByte-os cimzesi korlat. A HPC alkalmazasok altalaban gigabyte hegyekkel dolgoznak, es sok esetben a programszegmens is nagyobb, mint 256 mega.
"Miért ne lehetne általános vektor-procikat más matematikai műveletekre is használni, mint multimédia?" ill. " A Cell vektor-procijai miért nem "igazi" vektor-procik?"
Nem a multimedias igenyek szultek a vektorprocesszorokat (a PC-k vektorkiterjeszteseit mar igen!). Nem tudom, hogy a Cell elsodleges mag tartalmaz-e vektor egysegeket, de mintha az remlene, hogy csak a tarsprocikban van ilyen, es azokat explicite egy API-n keresztul kell majd hasznalni (valahogy ugy mint a DirectX-es GPU programozas). Tehat a mag csak annyira vektorproci, mint egy Mac, mas kerdes, hogy a vektor tarsprocesszor sokkal "kozelebb" van a maghoz, mint a GPU a CPU-hoz egy PC eseten.
Elmagyarazom miert szoktak szeretni az igazi vektorprocesszoros gepeket. Ha en ilyet szolok Fortran90 nyelven (tudom elavult, de a szuperszamitogepesek meg mindig csipazzak):
akkor ezt mar a forditoprogram olyan gepi kodra forditja, hogy az elmeleti maximalis teljesitmeny kozeleben dolgozik a CPU. Nem kell szoszmotolni, hogy most akkor melyik tarsprocinak adjuk ki, nem kell speci API hivasokkal operalni ..... Meg lehet, hogy olyan forditoprogramjuk lesz, ami kepes a fenti trivialitast kiszurni, de az is lehet, hogy mar egeszen picit bonyolultabb konstrukciokat expliciten kell API-n keresztul leprogramozni. Esugye HPC alkalmazast portolgatni nagyon genyo (es draga) dolog, mert baromi nehez validalni a reszeket.
Egyebkent nagyon latszik a Cell-en, hogy HPC-s gyokerei vannak, de az is latszik rajta, hogy az elkeszult termek mar nem igazan jo ebbe a szegmensbe. Szinten az IBM altal gyartott PPC440 (BlueGene/L) valo ide, azzal meg multimediazni nem hatekony.
Csak referenciakeppen: a PPC440 (BlueGene) elso prototipusanak elkeszulte utan egy honappal mar a theoretical peak 90%-at ertek el HPL benchmarkban. Egy honap mulva nem fog meg 20 GFlops-ot sem teljesiteni a Cell mag.
Meg egy apro terminologiai dolog. Emlegettel parhuzamosithato szamitasokat (marminthogy abban jok a vektorprocik). Ez igy kicsit csusztatas:
- Az olyan alkalmazasokban, ahol maga az algoritmus sok parhuzamositasi lehetoseget tartalmaz (pl. rendezesek), ott nem igazan hatekonyak a vektorprocik. Illetve nem gyorsabbak, mint hagyomanyos tarsaik. Cserebe viszont dragak. A parhuzamosithatosagot hagyomanyosan erre a szintre ertjuk.
- Van egy alacsonyabb szintu parhuzamossag ez az un. loop-carried parallellism. Ebben nagyon jok a vektorprocik es nem tul jok a a hagyomanyosak, mert nagyon koltseges algoritmikusan parhuzamositani.