"Itt akár 40-50 GB-ról is beszélhetünk, így hiába van GPU-s gyorsítás ezen a piacon, a mai gyorsítókártyákon nincs kellő mennyiségű fedélzeti memória. Ezért a cégek még ma is jellemzően százezres nagyságrendű node-okból felépülő szervereket használnak az adatok feldolgozására, így az egyes munkafolyamatok öt napig is futnak."
Kivancsi lennék ennek a pontos mechanizmusara. Mert 40-50 GB rendszermemoriat a Kaveri (Berlin) eleve nem kezel ("csupan" 32 GB-ot), tehat ott is fel kell osztani a munkat reszfeladatokra, mondjuk minimum 2-re. Ha pedig a munkat fel lehet osztani reszfeladatokra, akkor nem igazan latom a kulonbseget akozott, hogy 20 darabra daraboljuk, vagy 2-re. A GPU-val gyorsitott feldolgozas eleve a parhuzamosithato feladatokra van kitalalva. Nyilvan az ide-oda masolgatast egy SVM-képes APU-n meg lehet uszni, de erre eddig is voltak workaroundok. Ha egy tipikus modern dGPU PCIe 3.0-s interfeszet nezunk, az siman tud egy iranyban 10 GigaByte/mp tempoval adatot mozgatni. Hacsak nem a GPU-val vegzett szamitas baromi gyorsan megtortenik (ami nem tipikus), akkor az ide-oda masolgatas maximum fejlesztoi (programozoi) oldalrol maceras, de nem annyira lenyeges a futasido szempontjabol. At is lehet lapolni az adat masolasokat a szamitasi feladatokkal, ha valaki nagyon ra akar menni a teljesitmenyre.
Persze tudom en, hogy SVM-mel csomo mindent megsporolhat az ember, de nem vilagos szamomra, hogy miert tudna a Kaveri (Berlin) 5-10-szeres gyorsulast elerni pl. egy 1 TFLOPS-os dGPU-hoz kepest, ha amugy a feladat reszfeladatokra bonthato, es a hardver eleg gyorsan tudja mozgatni az adatokat a dGPU memoriaja es a rendszermemoria kozt oda-vissza. A programozo meg oldja meg, azert fizetik. Nehogy mar az olaj/gaz banyaszati iparban (ahol iszonyat penzek forognak elmeletben es gyakorlatban is) ne tudjak megfizetni a programozot...
[ Szerkesztve ]
