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

• #2571 Petykemano veterán S_x96x_S #2566

  Új Válasz 2020-02-06 08:02:20 #2571

  Ú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

  

  Petykemano

  veterán

  válasz S_x96x_S #2566 üzenetére

  "szerintem ha az AMD -ha "szemétkedni" akarna,
  akkor simán át tudná alakitani a ccx - et úgy, hogy a rendszerből
  4c/16thread -nek látszódjék ami amúgy 8c/16t .."

  Hogy?
  Mondjuk egy olyannal trükközhet, hogy 8 ép mag van a lapkán, és az, hogy ebből mi aktív és mi nem, az dinamikusan váltogatható. Így a turbózás ideje maximalizálható.

  Én elképzelhetőnek tartom, hogy 2 lépcsőben egyesítik a zen magokat - pont úgy, ahogy elvileg a zen is hasonlít két összeolvasztott bulldozer integer magra.
  Mindig az jut eszembe, hogy valamit csinálni kell, hogy lépést tartsanak az arm évi 30%-os növekményével. A magasabb frekvencia nem tart ki örökké.

  Aztán persze mivel a számítási kapacitás növelésének legnagyobb gátja az, hogy egy központi memóriából kell kiemelni a számolandó adatot ws az eredményt visszaírni, ezért valamikor biztosan jön az a fajta elosztott számolás, hogy minden számolóegység saját memóriával rendelkezik.
  (Jim Keller)

• #2569 Cifu félisten S_x96x_S #2566

  Új Válasz 2020-02-06 06:16:35 #2569

  Ú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

  

  Cifu

  félisten

  LOGOUT blog

  válasz S_x96x_S #2566 üzenetére

  A ciki inkább az, hogy a VMWare eddig jobban megérte a Hyper-V-vel szemben a nagy magszámú procik használatánál. Most igazából mindkét "nagy" szereplő lábon lőtte magát, az M$ féle 8/16 bázisú core-alapú licensz sem igazán értelmezhető megoldás, a VMWare féle is hasonlóan nyakatekert lett.

  Amíg nem lépnek tisztán core, de még inkább thread alapú elszámolásra, addig ez mindenesetre elég kellemetlen helyzet.

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