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

• #2 #16939776 törölt tag

  Új Válasz 2021-09-21 09:11:43 #2

  Ú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

  

  #16939776

  törölt tag

  Meg lehet oldani erőből: a programozók majd olyan programot írnak, ami optimális a HBM-nek, vagy a felhasználó kikapcsolja annak a használatát, ha több hátrányát látja mint előnyét. Lényeg az, hogy a HBM benne van a processzorban, és az az ügyfélnél van, onnantól a többi az ügyfél/programozó gondja.

• #5 #16939776 törölt tag Yutani #4

  Új Válasz 2021-09-21 09:29:54 #5

  Ú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

  

  #16939776

  törölt tag

  válasz Yutani #4 üzenetére

  Az irónia detektorotok látom nem működik..

  A cikk arról szól, hogy úgy kellene megoldani a problémát, de egyenlőre azt nem tudjuk, hogy intel-nél ez prioritás-e.

  [ Szerkesztve ]

• #10 #16939776 törölt tag Petykemano #7

  Új Válasz 2021-09-21 10:22:48 #10

  Ú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

  

  #16939776

  törölt tag

  válasz Petykemano #7 üzenetére

  Szerintem úgy, hogy prioritás a processzor közel teljes kiterhelése, mellette a tartósan alacsony késleltetés, úgy nem sok értelme lenne. Ne felejtsük el, hogy a koncepció a mobil vonalról jön, ahol pont a szakaszos terhelés a döntő, és amikor a kis magokat használja lehet akár másodpercekben mérhető a késleltetés, nem veszi észre senki.
  Jelenleg, ha van olyan feladatod aminek 4x több kis mag jobban fekszik, akkor veszel hozzá alacsony órajeles, sokmagos processzorokat, és átirányítod arra. Ez a big.LITTLE a svájci bicska esete, ide meg szerintem céleszközt vásárolnának szívesebben adott feladatkörre. Másik probléma a skálázhatósága: Látszólag lehet hogy rugalmas, de mennyi socketet kell kifizetni pluszban, ha kiderül hogy kell még 128db nagy mag egy feladat okozta plusz terheléshez. Veszel még 4-8 socketet vagy kettőt?

  Nem állítom, hogy nincs olyan mixed terhelés ahol ez jó lehet, megfelelő szoftveres háttér mellett, de a java tényleg nem ezt kívánja.

  [ Szerkesztve ]

• #34 #16939776 törölt tag Petykemano #13

  Új Válasz 2021-09-21 20:40:34 #34

  Ú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

  

  #16939776

  törölt tag

  válasz Petykemano #13 üzenetére

  A probléma továbbra is az, hogy gazdaságosan akkor fut a szerver, akkor termeli idő egység alatt a legtöbb pénzt, hogy ha a TDP lehetőleg ki van használva, addig a szintig, ameddig csak zavartalan a szolgáltatás minősége.

  Egy olyan processzornál ahol 8 nagy mag "egyenlő értékű" 36db kicsi maggal TDP szinten, és van benne összesen 48 kicsi és 8 nagy, ott kb.:~62,5%-os TDP-ig működik teljesen zavartalanul a szálak-erőforrások közti váltogatás. Fölötte, ahol a 36 kicsi és a 8 nagynak harcolnia kell a számukra fenntartott TDP keretért, már nő annak az esélye, hogy késleltetés tüskék keletkezzenek. Addig ameddig egy hagyományos processzornál ez mondjuk 90%-os TDP fölött jön elő.

  Röviden tök nagy biznisz lehet a szolgáltatás minőségét kockáztatni azért, hogy egy olyan működési tartományban lehessen gyorsabb és egyszerre energiatakarékosabb a leendő szerver processzor, amiben lehet ,hogy nem is óhajtják azt használni.

  Ha azt mondanák hogy tudunk 64 magos processzort csinálni ami 280W-ból sok szálra optimalizált terhelésnél olyat mutat mint egy 40 magos 400W-os akkor azt mondanám hogy OK. De ezt a marketing osztály gyomra nem venné be..

  [ Szerkesztve ]

• #40 #16939776 törölt tag Petykemano #35

  Új Válasz 2021-09-22 00:50:37 #40

  Ú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

  

  #16939776

  törölt tag

  válasz Petykemano #35 üzenetére

  48x=TDP
  (TDP/48x)*((36x/2)+12x)=0.625TDP
  (egy magra eső TDP)*(egyensúlyi állapotban aktív magok száma)

  Ha innen közelítjük meg ahogy leírod, akkor a normál processzornál a terhelés növekedésével csökkenő a magok órajele, itt meg elképzelhető olyan szervezés, hogy 4-5 kicsi magot ki kell kapcsolni ahhoz, hogy egy nagyot be lehessen kapcsolni, vagy fordítva, hogy át lehessen szervezni az energia felhasználást. Azt kell mérlegelnie a logikának, hogy ez a lépés megéri-e. Ha meg "kézi vezérléssel" prioritást adsz egy olyan szálnak, ami miatt 1 db nagy magot "be kell kapcsolni minden áron" ilyenkor +2-(4..5) szállal fog gazdálkodni a processzor a következő váltásig.
  Itt az energiagazdálkodás szintjén, meg lehet azt fogalmazni, hogy tovább esetleg nem éri meg az óra-jelet folyamatosan fel-le léptetni, mert arra ex-has 10-10 db üres órajel ciklus a büntetés minden lépésnél. Inkább olyan magot kell tervezni, ami kizárólag fix 5Ghz(nagy) és fix 3Ghz-re(kicsi) van optimalizálva jelterjedésileg és legyen elvárás, hogy 5Ghz és 3Ghz-en tartson el 10 órajelciklusig, amíg teljesen be vagy ki kapcsolható, ne 600Mhz-en! Az effektív 600Mhz-et úgy is el lehet érni, hogy a 3Ghz-es mag 20%-os kitöltési tényezővel üzemel, ekkor az idejének 80%-át kikapcsolva tölti.

  [ Szerkesztve ]

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