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

• #340 con_di_B tag

  Új Válasz 2011-10-12 13:50:05 #340

  Ú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

  Azért ennél az új ütemezőnél valami rendszerszintű átgondolásra lenne inkább szükség, megjelenhetne egyfajta CPU "driver", ami application profilokkal elmeséli az OS-nek, hogy hova, miként érdemes ütemezgetni a rendszert.

  Ez annál is inkább értelmes, mert pl. a Sandy/Ivy vonalon ott van az egyik fontos kérdés, hogy L3-ba ki írhat, ki nem, másrészt meg a Hyper-Threadingnél épp ellenkezőleg fest az ideális ütemezés, ott az a nyerő, hogy ha először minden magra jut értelmes meló, és csak utána a "virtuálisaknak". De ez meg csak akkor igaz, ha nem ugyanaz a program fut két szálon, ami elsőre hülyeségnek hangzik, de OpenCL-ben kb. mindig ugyanaz a programkód fut több példányban.

  AMD-nél ugyanez, az egy dolog, hogy megcsinálják ezt az ütemezést, ami általában nyerő, de ott meg az a kivételes eset, hogy ha erős FP terhelés van, akkor meg pont fordítva kell ütemezni, hogy ne essen vissza az FP throughput.

  (Egyébként meg ha egyszer csinálnának cache-en belüli power gate-inget - nem lepne meg ha már most is volna -, akkor meg pláne ilyen lenne.)

  Szóval szerintem ez mostanra bonyolultabbá vált, minthogy egyetlen ütemező algoritmussal kezelhető lenne az összes eset. Windows 8 alatt meg ugye bejönnek még az ARM-os procik is stb. Nem lehet mindenkinek jó, ha nem passzolják le valahogy a felelősséget.

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