Nagyobb figyelmet helyez az egyszálú tempóra a UserBenchmark

Mindezt a sokmagos CPU-k felé menetelő piacon. A Ryzen megjelenése óta ez már a második nagy átalakítás a CPU-kat rangsoroló weboldalakon.

A UserBenchmark bejelentette, hogy átalakítják a teljesítményt rangsoroló algoritmusukat, ami tulajdonképpen nem lenne elsőre meglepő, hiszen a korábbi megoldásuk 30%-ban értékelte az egyszálú, 60%-ban a négyszálú és 10%-ban a több, akár 64 szálat is kezelő mérések eredményeit. Ezek alapján állított fel egy listát a processzorok erősorrendjéről, méghozzá a felhasználók által beküldött eredményeket figyelembe véve. Ez ugyan nem túl szakszerű, hiszen rendkívüli módon különböznek az egyes CPU-k melletti komponensek, de javarészt szintetikus mérésből áll a UserBenchmark szoftvere, így sok esetben nem annyira érzékeny például a memória sebességére. A komoly hiányosságok mellett is nagyon sokan döntenek a UserBenchmark rangsorolása alapján, hiszen egyszerűen vannak átadva bonyolult információk, nem tájékoztatva a felhasználót arról a tényezőről, hogy mindez mennyire alkalmazásfüggő.

Viszont látjuk mi történik a piacon, az Intel és az AMD is erősen növeli a processzorok magszámát, előbbi cég jövőre 10-magos megoldásokat hoz a normál asztali platformba, míg utóbbi vállalat már most rendelkezik 16-magos Ryzennel. A HEDT-ről nem is beszélve, ahol jelenleg 32 magig lehet nyújtózkodni. Nyilvánvaló, hogy meghaladtuk azt az kort, amikor csupán 10%-ban kellene figyelembe venni négynél több szálat dolgoztató méréseket, így a UserBenchmark lépett is, csak éppen nem úgy, ahogy azt sokan várták.

Az új és a régi súlyozás A régi és az új súlyozás
Az új és a régi súlyozás [+]

Az új algoritmusuk mostantól mindössze 2%-ban veszi figyelembe 64 szálat is kezelő mérések eredményeit, 58%-ra csökken a négyszálas, illetve 40%-ra nő az egyszálas eredmények súlya a kiértékelésnél. A változást a UserBenchmark azzal magyarázza, hogy a játékok sebességét leginkább az egy szálon leadott teljesítmény határozza meg. A probléma ezzel az, hogy nem igaz, legalábbis ennyire általánosan leírva semmiképpen sem. Amikor a játékokról beszélünk, akkor legalább öt esetet érdemes megkülönböztetni. Valójában persze többet is, a legjobb minden videojáték-motor egyes verzióit külön kezelni a skálázódás tekintetében, de úgy meg nagyon nehéz rangsorolni a hardvereket, mert iszonyatosan sok tényezőt kell figyelembe venni. Ez tipikusan az erősorrend szimpla számmal történő meghatározásának hátránya, egyszerűen annyira le kell szűkíteni a mintát, hogy az már nem mutatja a valóságot, amit egyébként a többmagos processzorok érájában tulajdonképpen át sem lehet adni, a legjobban akkor jár a vásárló, ha a futtatandó, konkrét programokat elemezve választ processzort.

A problémák mellett ugyanakkor elmondható, hogy a játékoknak valóban van egy olyan része, amely nem igazán skálázódik egy szál fölé. Ezek a tipikusan régi videojáték-motorra írt, elavult grafikus API-kat használó alkotások. A gond az, hogy ezt a tényezőt sokan a grafikus API-ra vezetik le, például a DirectX 11 egyszerűen nem tud többet, és ez okoz limitet. Tekintve, hogy mennyire ki volt hangsúlyozva az elmúlt években a DirectX 12 és a Vulkan API többszálú feldolgozás melletti hatalmas előnye, nem is érdemes ezért hibáztatni a felhasználókat, hiszen kaptak egy egyszerű információt, ami megragadt bennük. A valóság azonban az, hogy a modernebb, illetve az úgynevezett GPU-driven pipeline rendszert használó videojáték-motorok még DirectX 11 mellett is egészen kellemesen skálázódnak, akár nyolc vagy még több szálra is. Ebben persze nagyon sok segítséget kapnak a grafikus meghajtókból, amelyeket gyakorlatilag annyira programspecifikusan optimalizálnak, hogy értékelhető sebességűvé teszik a DirectX 11-et is. Persze van egy pont, amikor már nem lehet mit kezdeni az API-val, de amíg skálázódik, addig a gyártók nagyjából elmennek. Erről egyébként Dan Baker korábban bővebben beszélt egy előadása alkalmával, és elmondta, hogy ha az AMD és az NVIDIA nem biztosítanak rendkívül specifikus, skálázódás elősegítő optimalizálásokat a grafikus meghajtóban, akkor az Ashes of the Singularity című játék, DirectX 11-es módban nagyjából harmadakkora teljesítménnyel futna. Tehát az API valóban limit, csak nem megkerülhetetlen.

Ezeken túllépve a DirectX 12 és a Vulkan API-k explicit párhuzamosítású parancsgenerálást alkalmaznak, így ha egy alkalmazás nincs úgy megírva, hogy ezt korlátozza, akkor elméletben minden parancsgenerálás mehet külön processzormagon. A gyakorlatban persze ez nem ilyen egyszerű, a videojáték-motorok az explicit API-kra lassan tértek igazán át, tehát a régebbi játékok ugyan támogatták ezeket, de az igazán jó működéshez új motorstruktúra kell. Ennek részleteiről korábban írtunk, és ez tulajdonképpen le is fedi a tipikus strukturális lehetőségeket. Ilyen formában nem lehet általánosítani, mert egészen nagy a szórás a játékok között a skálázódás tekintetében. Némelyiknél valóban kritikus az egyszálú teljesítmény, míg más alkalmazás a nyolcnál több magot is meghálálja. Ha nem így lenne, akkor az Intel és az AMD sem ilyen processzorokat fejlesztene.

A konkrétumokat tekintve a UserBenchmark friss algoritmusa szerint a 200 dollár körül megvásárolható AMD Ryzen 5 3600 ugyanolyan erős, mint az 1850 dolláros Intel Core i9-9980XE processzor, de fordítva is van érdekesség, többek között az 170 dolláros Core i3-8350K a 270 dolláros Ryzen 7 2700X elé van rangsorolva. Eközben a valóság borzalmasan messze áll mindkét esettől.

Egyébként nem ez az első alkalom, hogy átalakítást kap egy a CPU-kat rangsoroló weboldal vagy teszt. A CPU-Z például két éve jelentette be, hogy átírták a programot, mivel az eredeti kódot a Ryzen a korábbi architektúráknál sokkal hatékonyabban futtatta, így nagy előnyre tett szert. Emiatt módosítottak az alkalmazáson, hogy az eredmények igazodjanak a többi program méréseihez. Ez egy nagyon érdekes tényező, és mutatja a CPU-Z szintetikus méréseinek problémáját is. Kvázi előre meghatározták, hogy mit szeretnének látni, és aszerint dolgoztak. Végeredményben pedig egy döbbenetes dolog történt: olyan eredményt ad a program, amilyet látni akartak. Emiatt érdemes kiemelten a gyakorlati mérésekre fókuszálni, mert a szintetikus tesztek egy részét – tisztelet a kivételnek – úgy írják meg, hogy már a fejlesztés elején le vannak osztva a lapok.

Ha már mindenképpen fontos a szintetikus mérés, aminek kétségtelenül megvan a maga haszna, akkor olyan programot érdemes elővenni, amely erősen alkalmaz assembly szintű, gyártóspecifikus optimalizálást (például az AIDA64), hogy lehetőség szerint nagyjából minden ki legyen facsarva az egyes CPU-kból. Ettől persze még nem biztos, hogy az eredmények a gyakorlati mérésekhez hasonlók lesznek, de legalább maga a teszt törekszik arra, hogy a lehető legjobb eredményeket prezentálja.

Azóta történt

Előzmények

Hirdetés