"főképp a gyér memória sávszél miatt"
Az max. akkor szamit, ha tul keves feladatot csinalsz egy adott memoria tartalomra leosztva, azaz a GPU tul hamar vegez a feladataval, nem dolgozik eleget az adatokon. Ha ugyanis rendesen dolgozik a GPU, nem csak vegigszalad az adatokon, akkor a mem.savszelesseg szukossege nem lenyeges, hiszen sokkal tobb ido telik el az adatokon valo szamitasokkal, mint az adatok mozgatasaval. Amugy meg a dGPU-k sajat memoriajahoz valo hozzaferes -- elvileg -- sokkal gyorsabb, mint az iGPU eseteben a rendszermemoriahoz valo hozzaferes, SVM ide vagy oda. Teny, hogy ha keves adatot kell sokat ide-oda masolgatni, akkor az SVM jol johet, de mar eddig is baromi sok feladatot megoldottak dGPU-val, ide-oda masolgatassal is. Aki pedig mar volt annyira ugyes, hogy athidalja a dGPU korlatait, annak hiaba adsz SVM-et, a keves TFLOPS miatt maradni fog inkabb a dGPU-nal.
"_érdemes_ lesz szakértő programozóra beruházni, vagy valakit kitaníttatni"
Hat nemtom... En ha egy olaj/gaz banyaszati ceg lennek, es milliardok (USD-ben) forognanak kockan, nekem eddig is erdemes lett volna valakit kinevelni OpenCL-re vagy CUDA-ra, es venni egy csinos GPU szervert. Es mivel sok GPU szerver termekleirasaban pont ezek az iparagak szerepelnek (pl. a Supermicro weblapjarol egy idezet: "GPU Server, Mission-critical app., enterprise server, oil & gas, financial, 3D rendering, chemistry, HPC"), egesz biztos, hogy ez meg is tortent sok cegnel. Lehet, hogy az AMD talalt egy banyasz ceget, aki ezzel nem volt hajlando foglalkozni, es inkabb CPU-val oldotta meg a szamitasokat -- csak akkor meg fura, hogy nem a banyasz ceg CIO-ja vagy CTO-ja allt ki a szinpadra eloadni, hogy "Mi csak a HSA-ra vartunk, addig nem foglalkoztunk holmi 16 TFLOPS-ra kepes szutyok GPU szerverekkel, nem, mi az 1 TFLOPS-ra sem kepes Berlinre vartunk, nekunk semmi mas nem felel meg" 
[ Szerkesztve ]
