- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
Hirdetés
-
Premier előzetesen a Gray Zone Warfare
gp A mai naptól hivatalosan is elrajtol a játék korai kiadása PC-n.
-
Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
it Egyre nagyobb probléma az AI hallucinálása – most az osztrák adatvédelmi hatóság veheti elő a ChatGPT miatt az OpenAI-t, alapvetően a GDPR megsértése miatt.
-
Saját Redmi Note 13 Pro+ a világbajnok focicsapatnak (és indiai rajongóiknak)
ma Argentína nemzeti válogatottjának mezével díszítik az új Redmi különkiadást.
Új hozzászólás Aktív témák
-
Fiery
veterán
Amennyiben az AnTuTu nem assignolja (nem rendeli hozza) az egyes threadeket specifikusan megadott magokhoz, akkor elvileg a Linux kernel utemezojen mulik, hogy hova pakolja a threadeket. Elmeletben tehat meg lehetne oldani, hogy inkabb a legerosebb magok szamoljanak mindent, me'g akkor is, ha tobb szal terheli oket, mint ahany mag van bennuk osszesen. Azonban, van egy tippem ra, hogy az AnTuTu assignolja a threadeket, legalabbis elmeletileg egy "rendes" tobbszalu (multi-threaded) benchmark igy kellene, hogy mukodjon. Ha pedig a threadek csak adott magokon futhatnak, akkor kenytelen lesz a SoC minden magot egyszerre uzemeltetni.
Egyebkent en szemely szerint nem vagyok meggyozodve rola, hogy nagyobb osszteljesitmenyt (khm, pontszamot) lehetne elerni a 2 nagy clusterrel; mint ha az osszes cluster mukodik, bar throttlingolt (alacsonyabb) orajelen. Az megint mas kerdes, hogy az altalanos felhasznalas soran teljesen mindegy, hany mag van, 4 mag boven sok lenne a legtobb esetben, csak uzemeljenek magas orajelen.
[ Szerkesztve ]