AMD FX-8350: Vishera, a lánctalpas cölöpverő

Rövid visszatekintő

A szinte éppen egy éve debütált, Bulldozer-alapú AMD FX asztali processzorcsalád nem váltotta be a hozzá fűzött, talán túlzó reményeket. Ez több különböző okra vezethető vissza. Egyrészt néhány korábbi termékéhez hasonlóan az AMD ezt a fejlesztést is egy hosszabb távú célnak rendelte alá, ami nem más, mint az x86-os CPU-magok, valamint az általános számításokra is befogható GPU egyre szorosabb összefűzése. Akik olvasták tavalyi tesztünket, azok tudhatják a Bulldozerről, hogy felépítése radikálisan eltér mind elődeiétől, mind jelenlegi versenytársaiétól. A mikroarchitektúra tervezését jó néhány évvel ezelőtt, szinte nulláról kezdték a mérnökök, ami valószínűleg nagyban közrejátszott abban, hogy az első, 2009-es céldátum helyett csak tavaly, azaz 2011-ben lett kézzelfogható termék a munkagépről elnevezett fejlesztésből.

A teljes rendszer alappilére a cluster-based multi-threading (klaszteralapú többszálúsítás). A multi-threading (magyarul többszálúsítás) röviden valamilyen speciális hardveres megoldást takar, melyben a végrehajtószálak minden esetben osztoznak bizonyos erőforrásokon. Az, hogy ezek a bizonyos egységek pontosan mit takarnak, az mindig a koncepciótól függ. A többmagos megoldásokkal (multi-core) szemben – mely több önálló, teljes értékű magot kapcsol egy lapkába a számítási teljesítmény növelése érdekében – ezen eljárás fő célja a már rendelkezésre álló erőforrások minél hatékonyabb kihasználása.

A cluster-based multi-threading koncepció félig-meddig a Sun által tervezett SPARC architektúrás (azaz nem x86!) UltraSPARC T1 és T2 esetében bevezetett, "chip multi-threading" nevű rokonra hasonlít. Ennek dióhéjban az a lényege, hogy egy lapkán belül több mag (az említett T1 és T2 kapcsán maximum 8) található, melyek osztoznak bizonyos erőforrásokon (cache, FPU stb.), és emellett egy-mag(juk) képes SMT-szerűen több szálat (4-8) is futtatni, melyeket a rendszer – a Hyper-Threadinghez hasonló módon – különálló végrehajtó egységeknek ismer fel.

[+]

Az AMD koncepciója a fenti sematikus ábrán figyelhető meg. Abban a tekintetben, hogy a processzoron belül mi az az elemi feldolgozó egység, amely a támogatott utasításkészletek összes utasítását fel tudja dolgozni, a korábban megszokott "mag" kifejezést a Bulldozerben a "modul" vette át. A modulok belül több alegységre bonthatóak, amelyek közül néhányból teljes egészében kettő van, ezek dedikáltan egy-egy szálhoz tartoznak, míg mások mindkét utasításfolyamot kezelik felváltva vagy párhuzamosan. Az utasítások végrehajtása a következő utasítások kiválasztásával, azok előfeldolgozásával és dekódolásával kezdődik, ezeket az összefoglaló néven front-endnek hívott megosztott részegységek végzik, órajelenként váltva a két szál között. A szálak utasításait egyetlen 64 kB méretű, kétutas csoportasszociatív L1 I-cache (utasítás cache) tárolja.

[+]

Mindkét programszálhoz dedikált egész számos műveletvégző egység tartozik, amelyeket az AMD magoknak nevez. Ezek egyrészt az adott szálhoz tartozó összes belső műveletet és azok eredeti programsorrendjét tárolják a Re-Order Bufferben (ROB), másrészt végrehajtják az egész számokon dolgozó SISD utasításokat és kezelik a memória-alrendszert. Külön L1 adatcache-sel rendelkezik a két integer mag, méretük 16-16 kB. Modulonként egyetlen FPU-t találunk, amely megosztott a két programszál között: feladata az összes lebegőpontos számítás, valamint a egész számos SIMD funkciók ellátása. Egy modul 4 db 128 bites végrehajtót tartalmaz, amelyek közül a 2 FMAC jellemzően lebegőpontos számokon dolgozik, kettő pedig egész számokon. Az L2 cache mérete 2 MB, 16 utas asszociativitású és két magja közösen használja, míg a különálló modulokat egy méretesebb (4-8 MB-os), 64 utas asszociativitású L3 cache köti össze egymással.

Piledriver v2: Bulldozer kipofozva

A moduláris Bulldozer mikroarchitektúra kidolgozása után az AMD előtt állt a következő nagy feladat: a lehető legkevesebb idő alatt, radikális módosítások nélkül, az egységnyi órajel alatt végrehajtandó utasítások számát megemelni a magórajellel párhuzamosan. Ehhez született meg a Piledriver v2 (a Piledriver magyarul "cölöpverő" jelentéssel bír), mely többek között tartalmazza a Trinity Piledriver v1 moduljai esetében már látott, Cyclos által kifejlesztett Resonant Clock Mesh órajelelosztási technológiát, aminek fogyasztáscsökkentő hatását teljes egészében az órajelnövelésre fordították.

Mint a képen látható, a Bulldozer fogyasztásának 15-35%-áért maga az órajelhálózat a felelős. A Resonant Clock Mesh – amelynek a Trinity volt az első kereskedelmi forgalomba került megvalósítása – jelentősen csökkenti ezt a fogyasztási tényezőt, ami azonos órajelen kisebb TDP-t, illetve azonos TDP mellett magasabb órajelet jelent. A Resonant Clock Mesh megvalósítása a Bulldozer meglevő órajelrendszerére épült a Piledriverben; a Cyclos szerinti optimalizációkkal a következő generációkban akár meg is duplázható a fogyasztási megtakarítás.

A most debütáló modulokban a dedikált egész számos végrehajtók működését is némileg átszervezték. A Bulldozer magjaihoz hasonlóan a Piledriver integer műveletvégző egységeit is 2 ALU (Arithmetic-Logic Unit) és 2 AGU (Address Generation Unit, címszámító egység) alkotja, viszont míg utóbbiak feladata a Bulldozerben a memóriacímek kiszámítására korlátozódott, addig itt a regiszterből regiszterbe történő elemi 32 vagy 64 bites adatmásolásokat is el tudják végezni.

• A legegyszerűbb ilyen másolást a MOV regiszter1, regiszter2 x86/x64 utasítás végzi, mely a regiszter2 tartalmát átmásolja regiszter1-be. Mivel az x86/x64 integer utasítások egyik bemenő regiszterparaméterüket felülírják az eredménnyel, ezért sokszor annak tartalmát át kell másolni egy másik regiszterbe a további munkához, ezáltal az ilyen MOV utasítások a leggyakoribb műveletek közé tartoznak a programokban; a Piledriver-magok az AGU-k segítségével 4 regisztermásolást tudnak végrehajtani órajelenként.
• Ritkább eset az XCHG regiszter1, regiszter2 utasítás, amely a két regiszter tartalmát megcseréli. Ezt a dekóder két adatmásoló elemi műveletre fordítja le: az egyik a regiszter1 eredeti tartalmát másolja a regiszter2-be, a másik a regiszter2-ét a regiszter1-be; az AGU-k közreműködésével 2 ilyen XCHG utasítás futtatható le órajelenként egy-egy magban, vagy pedig egyetlen XCHG esetén az ALU-k tehermentesíthetők ennek végrehajtása alól, és más számítási műveletekkel foglalkozhatnak párhuzamosan.
• Kifejezetten ritka utasítás az XADD regiszter1, regiszter2, amely a következő műveletet végzi el: (1) összeadja a regiszter1 és regiszter2 tartalmát, (2) a regiszter2 eredeti tartalmát a regiszter1-be másolja, (3) az összeadás eredményét a regiszter2-be helyezi el; itt a 2. lépésben történő adatmásolást vehetik át az AGU-k.
• Még egy utasításban vállalhatnak szerepet az AGU-k: ez a Piledriverben újonnan bevezetett BEXTR regiszter1, regiszter2, regiszter3 utasítás, amely a regiszter1 eredeti tartalmából regiszter2 bitpozíciótól kezdődően regiszter3 darab bitet kiemel, és ezt elhelyezi a regiszter1-ben.

[+]

Mindezek mellett a v2 modul tartalmazza a v1 modul összes fejlesztését a Bulldozer óta:

• az integer magokban és a Flex FP-ben található ütemezők hatékonyságát a végrehajtó egységek kihasználásának növelése érdekében javították;
• az integer magok Load/Store egységében az olvasási sor méretét 40-ről 44-re növelték, azaz 10%-kal több, függőben levő memóriaolvasási műveletet kezelhet egyszerre 1-1 mag;
• az L1 adat TLB és az utasítás Translation Lookaside Buffer mérete egyaránt 32-ről 64 bejegyzésre nőtt, így kevesebb időigényes virtuális->fizikai memóriacím-fordítás szükséges a programok futása közben;
• az elágazásbecslés hatékonyabb lett, kevesebb téves elágazásjóslatot eredményezve: a hibrid branch prediktor két egységből áll, amelyek kétféle szempont szerint elemzik azt, hogy a következő órajelben mely utasítások kerüljenek beolvasásra az utasításcache-ből. Arra az esetre, ha a két jóslat ellentmond egymásnak, egy kis logika nyomon követi, hogy melyik jósol egy-egy adott szituációban korrektebben, és annak eredményét fogja használni legközelebb;
• a felhasználói és kernel mód között váltó instrukciók, az atomi (LOCK) műveletek, valamint a a lebegőpontos és az egész számos osztó utasítások végrehajtása gyorsabb lett; utóbbiak 10-60%-kal kevesebb órajelet igényelnek, míg az atomi műveletek akár 20%-kal kevesebbet;
• a Flex FP különböző alegységekből áll, az ezek közötti adattovábbítás további 1 órajellel növeli a művelet végrehajtási idejét; a Piledriverben a leggyakoribb ilyen eset a kiszámított eredmények memóriába írása (ez az adott lebegőpontos számítási alegységből a STORE alegységbe történő továbbítást jelenti), ami már nem igényli ezt a +1 órajelet;

[+]

• négy új utasításkészlet költözött be a CPU-ba: az Intel Haswellben alkalmazandó, 3 paraméteres FMA-utasítások (a Bulldozer csak a rugalmasabb, 4 paraméteres formákat kezeli); a 32 bites egyszeres és a 16 bites félpontosságú lebegőpontos számok közötti konverziót megvalósító F16C készlet két utasítása; továbbá a BMI- és TBM-készletek, amelyek egyrészt lehetővé teszik egy-egy 16, 32 vagy 64 bites egész érték bizonyos bitjeinek feltételtől függő csoportos 1-re állítását és/vagy törlését – kiváltva ezzel 2-3 korábbi külön utasítást –, másrészt implementálják az ANDNOT műveletet, és a BEXTR utasítás révén az ilyen számok összefüggő bitmezőinek kiemelését;
• az adat prefetcherek a spekulatívan előbetöltött adatokat azonnal 'legrégebben használt'-nak jelölik meg, kerülendő a valóban szükséges adatok későbbi felülírását téves jóslat esetén.

FX-8350: Vishera

A négy darab Piledriver v2 mikroarchitektúrára épülő modult tartalmazó, asztali környezetbe szánt lapkát egy orosz folyóról Vishera névre keresztelte el az AMD.

A vállalat által közölt hivatalos információk alapján a lapka területével párhuzamosan a tranzisztorok száma sem változott számottevően a közvetlen elődhöz képest. Ezzel együtt a gyártástechnológia sem esett át alapvető módosításokon, vagyis ez a modell is a GlobalFoundries 32 nanométeres HKMG SOI gyártósorain készül, mellyel korábban már alaposan meggyűlt a baja az AMD-nek. Többek között ezen problémák miatt sem hozta az előzetesen remélt, ám szükséges magas órajeleket az első generációs Bulldozer. A processzorgyártó a GlobalFoundriesszal közösen próbált fájdalommentes gyógyírt találni a problémákra, aminek eredményeképpen többek között számottevően sikerült csökkenteni a szivárgási áramot.

[+]

Mindez egyben azt is jelenti, hogy a másodszintű gyorsítótárak mérete maradt modulonként 2 MB, míg az L3 kapacitása továbbra is 8 MB. Ahogy a korábbi Zambezi, úgy ez a lapka is elsősorban a szerverek világának igényei alapján épül fel, így többek között található benne négy darab HyperTransport link, mely többprocesszoros rendszerekben a CPU-k közötti kapcsolatért felel. Ezekből asztali környezetben összesen egy darabot használnak ki, mely az északi híddal való adatcserének nyújt átjárót 2600 MHz-es órajelen. Az integrált memóriavezérlő természetesen most sem maradhatott ki. Ez a korábban bevett gyakorlat alapján kétcsatornás (dual-channel) működést biztosít, asztali rendszerek esetében hivatalosan egészen DDR3-1866-os szabványig, mellyel teoretikusan 29,86 GB/secundumos csúcsérték érhető el. A megoldás a Llano, a Trinity valamint a konkurens Sandy és Ivy Bridge megoldásával ellentétben továbbra sem foglalja magában az integrált PCI Express vezérlőt.

[+]

Utóbbiból is következik, hogy a tokozás semmit sem változott, azaz maradt a Socket AM3+. Újabb lapkakészletek most nem érkeztek, így az AMD hivatalosan a 900-as családot ajánlja az új jövevényekhez, de gyakorlatilag a régebbi megoldásokkal is működhet a Vishera.

[+]

Mivel sem az I/O infrastruktúra, sem pedig a tápellátás specifikációja nem változott, így elméleti síkon még a régebbi, pluszjel nélküli AM3-as foglalatba is beleilleszhetőek az új FX-ek. Természetesen ehhez szükség lesz egy újabb BIOS verzióra, melynek megléte értelemszerűen az alaplap gyártójának hozzáállásán fog múlni.

A foglalat nem változott

Amennyiben minden kritériumnak megfelel alaplapunk, akkor abban a mai nappal megjelent, összesen négy darab új FX processzor különösebb nehézség nélkül üzemeltethető lesz.

A fenti táblázatból könnyen leszűrhető, hogy a nyolcmagos FX-8350 a korábbi FX-8150 helyét veszi át, míg az FX-8320 az FX-8120 pozíciójába érkezik. Ezen a vonalon tovább indulva megállapíthatjuk, hogy a FX-6300 az FX-6100, míg az FX-4300 az FX-4100 korábbi szerepét kapja meg. Nálunk most első körben a leggyorsabb modell, azaz a nyolc magot magában foglaló, 4 GHz-es alapórajellel rendelkező FX-8350 járt. Az alapórajelet tekintve utóbbi 400 MHz-cel ketyeg gyorsabban, mint az FX-8150. A Turbo Core értékeket tekintve ez a fajta előny már kisebb, ugyanis az összes magra egyidőben kiróható, ugynevezett All Core Boost esetében már csak 200 MHz az újdonság órajelbeli előnye, míg a magok maximum felénél alkalmazható Max Turbo Boost az FX-8150 és az FX-8350 esetében egyaránt 4200 MHz.

Balra a régi, jobbra az új FX [+]

Az árazást tekintve az AMD az FX-8350-et a 235 dolláros Core i5-3570K ellen küldi harcba, míg az FX-8320 a 195 dolláros Core i5-3450 kihívója kíván lenni.

Deneb, Llano, Bulldozer, Trinity, Vishera

Közelmúltban megjelent, Trinity APU-ról szóló megatesztünkben összevetettünk négy darab négymagos processzort, melyek a Deneb, Llano, Bulldozer és Trinity kódnevű lapkák egyikét tartalmazták. Mindezt azonos órajel mellett is tettük, hogy megbizonyosodjunk a mikroarchitektúrális változások konkrét hatásairól. A Piledriver v2 alapú Vishera érkezésével kiegészítettük az akkor kapott eredményeket. Mindezt elsősorban egyfajta érdekességnek szánjuk, hisz a végleges termékek számítási teljesítményét éppúgy határozza meg az órajel, mint az egyetlen maggal egységnyi órajelciklus alatt végrehajtható utasítások száma. Mint azt már jól tudjuk, a Bulldozert és annak leszármazottait a korábbi generációknál jóval magasabb órajelre tervezte az AMD, emellé még a "mag" fogalmát is gyökeresen átértelmezték.

Balról jobbra: Bulldozer (Zambezi), Vishera, Trinity, Llano, Deneb [+]

A mérések ezen köréhez most összesen öt különféle processzort választottunk: FX-8350, FX-4170, A10-5800K, A8-3870K, Phenom II X4 980. A főszereplő FX-8350 kivételével mindegyik modell négymagos megoldás, így a Vishera-alapú CPU-ban két teljes modult tiltottunk le az alaplap UEFI-jében, miközben a magórajelt fixen 3000 MHz-re lőttük be. Az egyes platformokhoz a hivatalosan támogatott maximális memória-órajelet állítottuk be, ami a Phenom kivételével a másik négy processzornál 1866 MHz volt.

Vishera – Bulldozer – Trinity – Llano – Deneb [+]

Azonos magszám és órajel – eredmények

A gyökeresen új kialakítás miatt a Bulldozer-alapú megoldások egyik rákfenéje a renderelés. Ahogy látszik is, azonos órajel és magszám mellett jóval lassabbak, mint a Deneb vagy a Llano, amin a Piledriver v2 csak 1-2 százaléknyit tudott szépíteni.

A Premier Pro esetében már lényegesen jobb a helyzet. Itt a Bulldozer még lassabb volt, mint az azt megelőző mikroarchitektúrák, de a Piledriver v1 alapú Trinity nagyot lendített az eredményen, és határozottan az élre állt, amire a v2 még egy másodpercet pakolt rá. Photoshop alatt a Trinity még lassabb volt, mint a Deneb vagy a Llano, de a Vishera már elég volt ahhoz, hogy a korábbi megoldások elé keveredjen. Ez After Effects alatt még nem sikerült, de legalább a lemaradásból sikerült kicsit faragni.

A Cyberlink Powerdirectornak láthatóan tetszik az új Piledriver, amit egy viszonylag nagyobb gyorsulással viszonzott. A Sony Vegasnak ezzel szemben még mindig a Llano a kedvence. A mindössze egyetlen szálon dolgozó XviD szintén szerette a Piledriver második verzióját, míg a DivX ehhez képest csak kisebb mértékben gyorsult be.

Azonos magszám és órajel – további eredmények

Az x264 alatt nagyjából 2%-os gyorsulást tapasztalhattunk a Piledriver v1 és v2 között. A fájltömörítés már egy teljesen más történet, ugyanis ezek preferálják a minél nagyobb memória-sávszélességet és (L3) cache-t. Ebből kifolyólag a Vishera 7-Zip alatt rendesen ellép a mezőny többi tagjától, de említésre méltó gyorsulás figyelhető meg a WinRAR esetében is.

A Sorenson Squeeze és az AVG most is nagyon hasonló grafikonokat rajzol fel nekünk. Ahogy a közelmúltban, úgy most is a tesztek közül az Apache adta a legrosszabb eredményt, ami szerintünk valamilyen alapvető problémára vezethető vissza. Korábbi ígéretünkhöz híven ennek a jövőben megpróbálunk alaposabban utánajárni.

Az igencsak CPU igényesnek nevezhető Far Cry 2 alatt is megfigyelhettünk egy jó adag gyorsulást, bár a Deneb és Llano alapú megoldásokhoz ezzel csak közelebb férkőzött a Vishera, megelőzni nem tudta azokat.

Az összesített eredmények alapján elmondhatjuk, hogy azonos órajel és magszám mellett a Vishera nagyjából 10%-kal gyorsabb az előd Zambezi kódnevű Bulldozernél. A korábbi Deneb és Llano kódnevű megoldásokat ugyan továbbra sem sikerült beérni, de legalább a hátrányból sikerült egy nagyobb mértékű lefaragást elérni, amivel a Deneb bő 7, míg a Llano kicsivel több mint 10%-ra van a Visherától. Arra ismét felhívnánk a figyelmet, hogy mindez önmagában nem túl sokatmondó információ, hisz a Vishera mind magszámban, mind órajelben a korábbi megoldások felett áll.

Tesztkonfig, fogyasztás, specifikációk

Tesztünkben tavaly ősszel frissített CPU tesztrendszerünket vetettük be, melyben a korábban használt alkalmazások jóval naprakészebb verziói kaptak helyet. Ennek pontos listája a következőképpen fest:

• WinRAR 4.20 (64-bit)
• 7-Zip 9.20 (64-bit)
• Cinebench R11.5 (64-bit)
• Autodesk 3ds Max 2012 (64-bit)
• Indigo Renderer v2.4.13 (64-bit)
• Adobe After Effects CS5 (64-bit)
• Adobe Premiere Pro CS5.5 (64-bit)
• Adobe Photoshop CS5.1 (64 Bit)
• Sony Vegas Pro 10.0e (64-bit)
• CyberLink PowerDirector 9 (64-bit)
• Sorenson Squeeze 7 (32-bit)
• DivX Encoder 6.9.2 (32-bit)
• XviD Encoder 1.3.2 (64-bit)
• x264 build 2200 (64-bit)
• Cockos REAPER v4.0 (32-bit)
• Apache 2.2.19 (32-bit)
• AVG Antivirus Free 2012 (64-bit)

• Crysis Warhead
• Battlefield 3
• Far Cry 2
• DiRT 3

Az alkalmazások döntő többsége képes 4-6 vagy akár több magot/szálat is kihasználni, de akadnak kivételek. Az XviD Encoder például csak egyetlen magot vagy szálat tud megtornáztatni, de a DivX is megáll valahol 2 és 3 között. A WinRAR az utóbbihoz hasonlóan működik, és a két fájltömörítő közül ilyen szempontból a 7-Zip kicsit jobban viselkedik. Az előbbi alkalmazáshoz kapcsolódik, hogy jelen tesztünkben már a legújabb, 4.20-as verziót használtuk, ami számottevően gyorsabb a korábban kipróbáltaknál. Szintén a közelmúltban frissült az x264 nevű enkóder is, melyből a 2200-as build került bevetésre.

Ahogy korábban már említettük, az új sorozat leggyorsabb tagja, az FX-8350 vendégeskedhetett nálunk, így nem maradhatott ki az FX-8150 a versenyzők közül, ami mellett még a négymagos FX-4170 is helyet kapott. A két nyolcmagos FX-hez feltelepítettük a Microsoft által korábban kiadott ütemező frissítéseket. Az APU-k köréből a közelmúltban alaposan letesztelt A10-5800K-t láttuk vendégül, és a korábbi Phenom II sorozat két leggyorsabb tagját is bevettük a buliba, név szerint az X6 1100T-t és az X4 980-at. A konkurens Intel oldaláról a magasabb ár ellenére a Core i7-3770K szereplése nem volt kérdéses, mely mellé a Core i5-3570K is beválogatásra került. Nem hagytuk ki a továbbra is igen népszerű Core i7-2600K-t sem, melyet még az Ivy Bridge alapú i3-3220 követett a sorban.

FX-8350 [+]

A nálunk járt tesztpéldány saját doboz és hűtő nélkül érkezett, így ezekről egyelőre nem tudunk részleteket bemutatni.

[+]

A fogyasztás mérését továbbra is konnektorba dugható, digitális VOLTCRAFT Energy Check 3000 készülékkel végeztük, és minden esetben a monitor nélküli teljes konfiguráció értékeit vizsgáltuk. Mind az Intel, mind pedig az AMD platformon be volt kapcsolva az összes lehetséges energiagazdálkodási funkció (EIST, C'n'Q, C1E, C6, stb.).

Üresjáratban egy kisebb előrelépést láthattunk az FX-8150-hez képest, de a régebbi I/O infrastruktúra, azaz HyperTransport linken keresztül kapcsolódó alaplapi északi híd nincs túl jó hatással a fogyasztásra, ami itt is megmutatkozik. A másik oldalon ott a Trinity alapú A10-5800K, mely a modernebb környezetből adódóan magabiztosan áll az élen.

Terhelés mellett sem túl rózsás a kép, és ismét jól megmutatkozik az utóbb említett felépítésből eredő hátrány, valamint a 125 wattos TDP. Röviden megállapíthatjuk, hogy az FX-8350 – elődjéhez hasonlóan – meglehetősen magas fogyasztással bír.

Szorosan kapcsolódik a fogyasztáshoz, hogy az alapórajel alatt összesen négy (P1-P4), míg felette kettő (Pb1, Pb0) különböző P-STATE található. Előbbibe üresjáratban, míg utóbbiba terhelés mellett, a 125 wattos TDP keretben aktuálisan rendelkezésre álló tartalék függvényében kerülhetnek be az egyes magok.

Renderelés, tömörítés

Most nézzük immáron gyári magszám és órajel mellett a teljes mezőnyt!

Ahogy néhány oldallal korábban már láthattuk, a renderelés tipikusan az a nagyon jól párhuzamosított folyamat, ami nem igazán profitál sem a méretes L3 cache-ből, sem pedig az esetleges nagyobb memória-sávszélességből. Mindezek ellenére az FX-8350 jól muzsikált, amivel egy kicsivel az i7-2600K elé tudott kerülni. 3ds Max tesztünkben már ennél is továbbment a Vishera-alapú FX, és ha csak egyetlen másodperccel is, de az i7-3770K-t is legyűrte. Harmadik renderelő szoftverünkben is szépen muzsikált a főszereplő, amivel ismét a leggyorsabb Ivy Bridge elé tudott keveredni.

Jó néhányszor már megállapítottuk, hogy a fájltömörítők a renderelő alkalmazásokkal ellentétben kedvelik a minél nagyobb memória-sávszélességet és L3 cache-t, melyekből az FX éppen nem szenved hiányt. Itt ezzel együtt az i7-2600K környékére volt jó az FX-8350.

Videóvágás, szerkesztés

After Effects alatt viszonylag jól szerepelt az új jövevény, bár itt most kicsit távolabb volt az i7-2600K és az i5-3570K. Ahogy korábban a Trinity-nek, úgy most a Visherának is nagyon feküdt a Premiere Pro, ami egy megosztott első helyre volt elég az i7-3770K-val. Sony Vegasban ismét az i7-2600K volt a legközelebbi ellenfél, bár az i5-3570K sem volt egy karnyújtásnyinál messzebb.

Már korábban láthattuk, hogy a Powerdirector eléggé fekszik a Visherának, amivel újfent sikerült az i7-2600K elé kerülnie az FX-8350-nek. A Sorenson Squeeze szintén kedvelte a főszereplőt, ami most egy második helyet ért közvetlenül az i7-3770K mögött. Ezzel szemben a multi-threadingre háklis Cockos Reaper továbbra sem fekszik a Bulldozer-alapú megoldásoknak, ennek köszönhetően meglehetősen nagy hátrányba került az AMD új üdvöskéje. Itt jól láthatóan a HyperThreading sem túl hatékony, ugyanis az i5-3570K gyorsabb i7-es rokonainál.

Videókódolás, egyéb

A DivX-alapú kódolás nem fekszik kifejezetten az új FX-nek, amivel párhuzamosan a csak egyszálas XviD sem festett jobb képet. A sok szálat és számtalan utasításkészletet kihasználni képes x264 már lényegesen szimpatikusabb volt a Visherának, így az aktuális mezőnyben a leggyorsabb tudott lenni.

Photoshop alatt nem brillírozott annyira a 8350, ami 5-6 másodperces hátrányt jelentett a közvetlenül előtte álló Intel megoldásokhoz képest. Az Apache a Cockos Reaperhez hasonlóan egyelőre nem szívleli az AMD újabb megoldásait. Az AVG ezzel szemben látszólag kedvelte az új FX-et, amivel az négy másodperccel az i7-2600K mögött végzett a harmadik helyen.

Játékok

A Radeon HD 7970-nel párosítva, játékok alatt nem láttunk különösebb meglepetést. Alacsonyabb felbontás, valamint részletesség mellett meglehetősen nagy volt a differencia az Intel és az AMD processzorai között, ami alól csak a Battlefield 3 képzett kivételt. Full HD-re kapcsolva ez a differencia a Far Cry 2 kivételével szinte tejesen elolvadt, így mindegyik processzor képes volt játszható szintet produkálni. Ebből újfent az következik, hogy 1920x1080-hoz és a fölé az esetek döntő többségében elsősorban erős VGA, nem pedig erős CPU szükséges.

Tuning

Szokás szerint most is megnéztük, hogy mekkora órajeltartalék lapul még a főszereplő processzorban.

[+]

Ehhez most a korábban már bemutatott AMD vízhűtést vettük le polcunkról, mely gyakorlatilag nem más, mint az Antec műhelyében készült KÜHLER 920 AMD FX-re átszabott verziója. A turbót és az összes energiagazdálkodási opciót kikapcsoltuk, majd a gyári alapfeszültséget 1,35 voltról 1,4875 voltra emeltük. Rendkívül fontos, hogy az új FX az elődhöz hasonlóan rendelkezik egy olyan funkcióval, mely azért felelős, hogy a processzor semmilyen esetben ne léphesse át a gyárilag előre megszabott TDP küszöböt. Amennyiben ez megtörténne, akkor a rendszer automatikusan visszaveszi a magórajelet. Ugyanez igaz tuning esetén is, azaz ha nem kapcsoljuk ki az APM Master (gyakorlatilag TDP limiter) funkciót, akkor meglepődve tapasztalhatjuk, hogy a túlhajtás ellenére sem gyorsult elvárható mértékben a rendszer.

Mivel kivétel nélkül az összes AMD FX processzor teljesen szorzózármentes, azaz olyan, mint a Black Edition sorozat vagy a "K" jelzésű processzorok, így nem volt túl sok további teendőnk. A CPU magok órajelének szorzóját 24-re emeltük, amivel végül egy stabil 4800 MHz-et kaptunk. Ezen órajel felett már nem tudtuk stabilizálni a rendszert, hiába emeltük még feljebb a feszültséget. Ne feledjük, hogy a tuningpotenciál mértéke természetesen még egy adott modellen és steppingen belül is minden egyes processzornál eltérő.

Végül 800 MHz-cel sikerült megemelnünk az FX-8350 alapórajelét, ami kereken 20%-os túlhajtásnak felel meg. Az integrált északi híd szorzóját 11-ről 12-re húztuk fel, mellyel 2400 MHz-es üzemi frekvenciát kaptunk. Gyári beállítások mellett, 22 fokos környezetben a CPU magjai 44-45 °C-ig melegedtek, míg tuningolva már 70-72 °C-ig. Végül megnéztük, hogy az elért plusz 800 MHz mennyit számíthat néhány alkalmazásnál. Azt tartsuk szem előtt, hogy alkalmasint a különbség kevesebb mint 800 MHz, mivel a gyári alapbeállítások mellett a turbó aktív volt, ami négy mag esetében ennél a modellnél például 4,2 GHz-ig képes emelni azok órajelét.

Jól látszik, hogy bizonyos helyeken (WinRAR) már sokkal inkább az L3 cache sebessége limitál, mintsem a magok számítási teljesítménye. Ezzel szemben például az x264 szépen skálázódott párhuzamosan az órajel emelésével.

A feszültség és az órajel emelésének hatására most is tisztességesen megugrott a fogyasztás, ami több mint 110 watt pluszt jelentett a már amúgy sem alacsony alapórajel-értéken felül.

Összesítés, értékelés

Cikkünk végéhez érkezve jöjjenek az összesített eredmények!

A házon belüli csatát szemlélve megállapíthatjuk, hogy az új FX-8350 majdnem pontosan 14%-kal gyorsabb az előd FX-8150-nél. Az AMD által megcélzott konkurens Intel Core i5-3570K minimálisnak mondható mértékben, 1,2%-kal van a Vishera-alapú új jövevény előtt, míg a korábbi csúcs Sandy Bridge, a Core i7-2600K előnye nagyjából 4,3%. Az aktuálisan leggyorsabb Core i7-3770K Ivy Bridge már előrébb jár, ez konkrétan több mint 17%-ot jelent. Az összesítést az érdekesség kedvéért elvégeztük Cockos Reaper, valamint Apache nélkül is, így az FX helyzete egy fokkal jobb.

A relatív magas, 125 wattos TDP mutató, valamint fogyasztásos méréseink eredménye után nem ért minket túl nagy meglepetésként főszereplőnk – a konkurenciához mérten – igencsak gyenge teljesítmény/fogyasztás mutatója.

Verdikt

A Vishera kódnevű FX-8350 nem hozott gyökeres módosításokat az előd FX-8150-hez képest. A gyártástechnológia némi finomításon kívül nem változott, a mikroarchitekturális módosítások sem nevezhetőek igazán jelentősnek. Mindezek ellenére összesen 14%-kal sikerült túlszárnyalni a korábbi FX-et, ami egyáltalán nem nevezhető rossznak. Érdekesség, hogy a Sandy Bridge -> Ivy Bridge (2600K->3770K) váltás is pontosan ennyit hozott a konyhára, de egy másik, korábbi tesztünkből az is kiderül, hogy az első Phenom II X4 is ennyivel volt gyorsabb elődjénél. Természetesen azt újfent meg kell állapítsuk, hogy volt honnan javulni, hisz ahogy már elmondtuk, az első FX-ek nem sikerültek túl acélosan.

[+]

Mindenesetre az AMD most, egy évvel később tudott valamennyit szépíteni. Tavalyi tesztünkben azt prognosztizáltuk, hogy a Bulldozer, mint magas órajelre tervezett koncepció, 4 GHz felett kezdheti majd kimutatni a foga fehérjét, amit szerintünk néhány most látott eredmény már alá is támaszt. Ezek után lassan azt is leszögezhetjük, hogy a kisebbik, x86-os processzorokat tervező cégnek lényegesen jobban megy a már meglévő mikroarchitektúrák fejlesztése, mint a teljesen újak piacra dobása. Ebből kiindulva kíváncsian várjuk a jövőre esedékes Steamrollert, melyről már most tudni lehet, hogy a bemutatott Piledriverhez képest jelentősebb módosításokat fog felvonultatni mind gyártástechnológia, mind mikroarchitektúra terén.

[+]

No de egyelőre ne rohanjunk annyira előre! Ahogy feljebb megállapítottuk, az FX-8350 átlagosan egy szinten van az Intel Core i5-3570K-vel, ami jelenleg 55 000 forint környékén érhető el. A ma esedékes megjelenés miatt még nem ismerjük az FX-8350 kiskereskedelmi árát, de a 195 dolláros árcímkét a hazai viszonylatok alapján nagyjából 50 000 forintra saccoljuk. Mindez a hasonló teljesítmény mellett elsőre nem hangzik rosszul, hiszen ezzel majd olcsóbban juthatunk egy adott számítási teljesítményhez. Igen ám, de ezzel együtt a fogyasztás is jóval magasabb, ami megfigyeléseink alapján a vásárlók egyik felét abszolút hidegen hagyja, míg másoknak legalább olyan fontos szempont, mint a sebesség. Értékeléseinknél mind a két szempontot figyelembe véve tesszük le a voksunkat, így most egy erős tetszett plecsnit kap tőlünk az AMD FX-8350.

AMD FX-8350 processzor

Oliverda

Az FX-8350 CPU-t az AMD-től kaptuk tesztelésre.