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

• #19 con_di_B tag moli.hu #18

  Új Válasz 2011-11-22 11:20:42 #19

  Ú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

  

  con_di_B

  tag

  válasz moli.hu #18 üzenetére

  Most csak egy szerencsétlen megfogalmazáson rágódsz. Az ő eszközükkel magának az "elemi forrásfájlnak" (magyarul amiből kernelt kéne fordítani) a hossza az ami nem igazán releváns, értelemszerűen, más jellegű kódkomplexitásra (pl. funkcionális) ez már nem igaz.

  Nekem inkább az a problémám az elképzeléssel, hogy erre csak akkor lehet jó heurisztikákat mondani, hogy mit, hogy érdemes megírni/"lefordítani", ha már vannak helytálló best practices módszertanaink. Na ilyenek ma még nincsenek. Persze, rengeteg szép whitepaper volt/van, de a gyakorlatban minden ilyen elég könnyen be tud dőlni, elég egy driverfrissítés, amiben megoldanak valamit aminek eddig is gyorsnak illett volna lennie, csak eddig nem volt az... Vagy épp, hogy soha nem oldják meg...

• #12 con_di_B tag Abu85 #7

  Új Válasz 2011-11-18 08:38:19 #12

  Ú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

  

  con_di_B

  tag

  válasz Abu85 #7 üzenetére

  LoL

  Egy dologra egyébként jó lehet: meglévő C/C++/Fortran kódbázis HPC-sítésére. Viszont ha azok a kódok már eleve HPC-re vannak, akkor smemi szükségük ilyen megoldásokra, mert már eleve valamelyik natív környezetben lettek elosztott rendszerként lefejlesztve, ha meg most akarják átmókolni, akkor jobban járnának ha inkább újraírnák, csak még nem tudják.

• #6 con_di_B tag

  Új Válasz 2011-11-17 21:55:30 #6

  Ú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

  

  con_di_B

  tag

  És erre mi szükség van az OpenCL mellett? Csak a reference cardot néztem át, de abban nem láttam semmit, amit abban ne lehetne.

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