Anmelden mit
Registrieren | Anmelden

Benchmarks: Batman: Arkham City

Trinity auf dem Desktop: Vorab-Test von AMDs A10-5800K, A8-5600K und A6-5400K
Von , Chris Angelini

Auf den vorangegangenen Seiten haben wir uns intensiv mit der Performance von Trinitys x86-Kernen in Anwendungen beschäftigt, die entweder Fließkomma- oder Ganzzahlberechnungen nutzten. Inzwischen wissen wir, dass die neue APU in den meisten Aufgaben schneller ist als Llano, in einigen Szenarien aber auch langsamer sein kann. Letzteres gilt vor allem immer dann, wenn die gemeinsam genutzten Fließkommaeinheiten eines Bulldozer-Moduls stark belastet werden. Die große Frage lautet nun – und wie steht es mit der Grafik?

Batman: Arkham City ist der erste Titel, mit dem wir Trinitys 3D-Können testen wollen, und die Ergebnisse wissen zu gefallen. Bei 1280x720 liegt die A10-5800K gute 20 Prozent vor der A8-3850, weil ihre Grafik nicht nur effizienter ist sondern zudem noch schneller taktet.

Schade ist, dass 1680x1050 und 1920x1080 im High-Quality-Modus (aber ohne DX11-Features) selbst AMDs stärkste APU-Variante überfordern.

Alle 30 Kommentare anzeigen.
Auf dieser Seiten können keine Kommentare mehr abgegeben werden
Sortieren nach: Neueste zuerst | Älteste zuerst
  • Myrkvidr , 26. Juni 2012 12:15
    Danke für den frühen Test! Ich brenne schon auf den A10 Trinity - vor allem, wenn Dual Graphics nun wirklich funktionieren sollten (ich erinnere mich da an fürchterliche Testergebnisse in einem alten Llano Test) - das wäre inklusive einer kleinen Grafikkarte die perfekte Basis für eine kleine ITX-LAN-Box. Ich freu mich drauf :) 
  • Anonymous , 26. Juni 2012 12:57
    Mit wie viel Halbleitern sind die eigentlich bestückt nur mal so zur INFO?
  • pescA , 26. Juni 2012 17:08
    Zitat :
    Mit wie viel Halbleitern sind die eigentlich bestückt nur mal so zur INFO?

    Wie am Dieshot zu erkennen, sitzen CPU und GPU auf einem gemeinsamen Halbleiter. Also eins.
    Oder war das nicht die Frage?
    MfG
  • Prozente%@guest , 26. Juni 2012 17:09
    Mit Prozentrechnung habt ihrs irgendwie nich so oder?
  • benkraft , 26. Juni 2012 17:55
    Mit aussagekräftigen Kommentaren hast du's irgendwie nicht so, oder?
  • Brat , 26. Juni 2012 18:33
    ein kleiner einblick auf das was komme :p 
    wenn dank optimierung in 2013 full hd gaming ermöglicht wird,ist der umbruch geschehen :D 
  • Prozente%@guest , 26. Juni 2012 18:53
    @benkraft

    Zitat :
    Wie man sehen kann, wirkt sich die OpenCL-Beschleunigung massiv positiv auf die Performance aus. Brauchte die A10-5800K-APU im Software-Modus noch 2:11, verkürzt sich die Wartezeit auf 1:28, wenn die Devastator-GPU sich mit ins Zeug legt. Das ist eine Verbesserung um 32,8 Prozent, und man darf davon ausgehen, dass sich AMD ähnliche Zuwächse auch bei anderen Anwendungen erhofft, sobald andere Softwareentwickler herausfinden, wie sie ihren Code am besten für GPUs optimieren können.


    2:11 Min vs. 88 Min = eine Verbesserung? (was ist eigentlich eine Verbesserung in diesem Zusammenhang? hört sich nach stupider Übersetzung aus dem Englischen an) um 32,8%? Nein, man braucht im Vergleich nur 66,2% der Zeit und das ist dann eine "Verbesserung" von ca. 48,8%. (131/88)*100~148,8
  • Prozente%@guest , 26. Juni 2012 18:55
    Zitat :
    2:11 Min vs. 88 Min


    soll natürlich 88 sec. bzw. 1:28 Min heißen
  • pescA , 26. Juni 2012 22:20
    Nein, man braucht im Vergleich nur 67,2% der Zeit und das ist dann eine "Verbesserung" von ca. 32,8%. (1-88/131)*100~32,8%

    Und eine Verbesserung ist, wenn man die selbe Arbeit in geringerer Zeit erledigt. Wie würdest du das denn nennen? "positive Verkürzung"?
  • ich123@guest , 26. Juni 2012 22:49
    Danke für den Test & für das neutrale aber erklärende Fazit.
    AMD ist am richtigen weg!
  • ashrakk , 27. Juni 2012 00:22
    @doll-by-doll
    Du meinst bestimmt die Anzahl der Transistoren. Da AMD und Intel sich da gerne mal im 6-stelligen Bereich verzählen, muss man wohl warten, bis einer die kleinen Biester mit dem Rasterelektronenmikroskop nachgezählt hat ;) .
  • Anonymous , 27. Juni 2012 09:07
    Zitat :
    @doll-by-doll
    Du meinst bestimmt die Anzahl der Transistoren. Da AMD und Intel sich da gerne mal im 6-stelligen Bereich verzählen, muss man wohl warten, bis einer die kleinen Biester mit dem Rasterelektronenmikroskop nachgezählt hat ;) .


    Die liegen wahrscheinlich schon im 9-stelligen Bereich.
    ;) 
  • Binsenmeier , 27. Juni 2012 13:38
    Prozente%@GuestMit Prozentrechnung habt ihrs irgendwie nich so oder?


    2:11 Min vs. 88 Min = eine Verbesserung? (was ist eigentlich eine Verbesserung in diesem Zusammenhang? hört sich nach stupider Übersetzung aus dem Englischen an) um 32,8%? Nein, man braucht im Vergleich nur 66,2% der Zeit und das ist dann eine "Verbesserung" von ca. 48,8%. (131/88)*100~148,8



    Muuuuahahaha - Eigentooooooooooor!
  • Prozente%@guest , 27. Juni 2012 16:29
    @binsenweisheit

    muaahaha was? wenn du hier der schiedsrichter bist, dann erklär mir erst einmal wie es zu dem "eigentor" gekommen sein soll.

    @pesca

    die verbesserung beträgt wenn schon denn schon rund 49%, nicht 32,8%. man nimmt bei der prozentrechnung nicht einfach die differenz und deklariert sie als "ergebnis". ich dachte das hätte man in der schule gelernt. übrigens deine rechnung macht keinen sinn, ist einfach nur die inversion, was nutzt das?

    Zitat :
    As you can see, though, enabling OpenCL acceleration has a huge impact on performance. What once took 2:11 on the A10-5800K only takes 1:28 when the APU’s Devastator graphics core contributes to the effort. That’s a 32.8% improvement, and likely what AMD is hoping to see across the board as software developers begin figuring out how much of their code can be sped up using graphics resources.


    und eine verbesserung ist natürlich eine verbesserung und hat nichts mit arbeit und zeit etc. zu tun.
  • Brat , 27. Juni 2012 17:36
    alle sagen oben und du meinst unten ... systemverhalten lässt sich definieren
  • Prozente%@guest , 27. Juni 2012 18:24
    keine ahnung was der gefasel soll es geht nicht um unten oder oben: prozentrechnung lernt in der schule. die englischen autoren haben diese wohl nicht besucht. die deutschen "übersetzerlinge" haben es einfach stupide übertragen.

    da ihr anstatt zu überlegen lieber rumkeift erübrigt sich das ganze. es wird lieber die person angegriffen als der sachverhalt.
  • Prozente%@guest , 27. Juni 2012 18:24
    "das" gefasel
  • Prozente%@guest , 27. Juni 2012 18:29
    ich bin übrigens nicht der einzige dem das aufgefallen ist: siehe die kommentare von edgar_wibeau ab seite 2 im originalen artikel

    http://www.tomshardware.com/reviews/a10-5800k-a8-5600k-a6-5400k,3224.html
  • Binsenmeier , 27. Juni 2012 22:15
    @Prozentabverkauf - Och, weißt du, was man noch in der Schule lernt? Orthografie (Groß-, Klein- und Rechtschreibung), Grammatik (Zeichensetzung, Satzbau), sozialen Umgang.

    Btw, hast DU denn den Thread im Original weiter gelesen? Da gibt es auch noch Einwände gegen deine Rechenkünste.

    Aber ich merke, ich habe wohl die zwei goldenen Regeln missachtet.
    Don't feed the tro...
    und
    Never argue with an idi...
    (ergänzen Sie sinnvoll :D )
  • Prozente%@guest , 27. Juni 2012 22:41
    wieso "meine" rechenkünste? dem/r herrn/frau ist eben genau das auch aufgefallen. und ja es gab einwände u.a. vom autor. der hat das schnell abgetan und sich dann nicht mehr drum gekümmert. und wenn du den "thread" weiterverfolgst wird ihm dann letztendlich zugestimmt. hast du den thread bis zu ende gelesen, das ist meine gegenfrage? autoren sind nicht allwissend.

    dein orthografie-blabla interessiert (mich) nicht. ich bin hier eben nicht nicht in der schule meine satzbau ist mehr als zufriedenstellend meine zeichensetzung ausreichend, der wink mit dem "sozialen umgang"-pfahl bringt mich zum lachen bei solch eloquenten einwürfen wie

    "Muuuuahahaha - Eigentooooooooooor!" oder never argue with an idi...om(http://en.wikipedia.org/wiki/Idiom) habe ich für dich mal sinnvoll ergänzt. außer persönlichen beleidigungen kommt da wohl nich mehr viel substanz, oder?

    @topic

    ich mache mir mal die mühe das geschriebene aus dem amerikanischen thread "unvollständig" zu posten.


    Zitat :
    Edgar_Wibeau 06/14/2012 12:34 PM
    Hide
    -4+

    Regarding OpenCL Winzip:

    Erm, 88 seconds versus 131 seconds: "32% improvement" - that's percentage calculation done the wrong way. It's 100*88/131 = 67%, so 33% (not 32%) less time, but looking at the IMPROVEMENT (calculations done in the same timeframe) of 100*131/88 = 149%, so the improvement ist 49%, not 32%.

    Just my 63 THB.

    - hope this post won't be double cause I had to register first and it didn't show up yet


    die antwort des authors

    Zitat :

    cangelini 06/14/2012 1:19 PM
    Hide
    -4+


    Actually, I believe that you want the difference of the two times, which would be (131-88)/131, to get the improvement.



    Zitat :
    Edgar_Wibeau 06/14/2012 4:10 PM
    Hide
    -3+

    cangelini wrote :

    Actually, I believe that you want the difference of the two times, which would be (131-88)/131, to get the improvement.


    That's what you're doing. But this is 33% less time. Which is not the same as an improvement of 33%. It's an improvement of 49%.

    Let's be silly and talk money and bananas.

    One day you're getting 10 bananas for 3 Dollars. Your Dollar performs at 3 1/3 Bananas.

    Next Day you're getting 10 bananas for 2 Dollars. So that's 33% less Dollars for the same 10 bananas. One Dollar is now 5 bananas instead of 3 1/3. So your Dollars perform (improve) 33% better? Nope, they perform 50% better.

    That's what we call an improvement. Same bananas, improved Dollar by 50%.

    Same work (zipped content), same bananas, less Dollars (CPU time).

    Got me?



    Zitat :
    Edgar_Wibeau 06/15/2012 8:36 PM
    Hide
    -3+

    army_ant7: I Thought I'd read 32% in the article, now I read 32.8% Maybe I've missed the .8.

    Back to topic:
    Computing performance is calculations per timeframe. Time elapsed for a given amount of calcs is an inverse function for performance.

    I don't know the amount of resulting calculations (e.g. bytes compressed the correct way) in the winzip test, but let's assume it's 1,000,000 calculations. Just as an example. Let's break it down to caculations per second.


    Classic code:
    1,000,000 calcs / 131 seconds = 7,634 calcs / second

    OpenCL code:
    1,000,000 calcs / 88 seconds = 11,364 calcs / second

    Now, Percentage is

    100 * 11,364 / 7,634 = 149%
    Thus, an improvement of 49%.
    11,364 c/s is 49% higher than 7,634 c/s
    The other way around:
    7,634 c/s is 33% lower than 11,364 c/s

    Yet, less is not an improvement. Improvmement is the percentage above 100%

    That's the problem when the result (seconds) sits below the fraction line, it's an inverse function. Hope the terms in english are correct.


    No offense.



    und am ende...

    Zitat :
    army_ant7 06/16/2012 5:12 AM
    Hide
    -1+

    @Edgar_Wibeau: Oh yeah. It does look like you're right about this. I should've put it in an algebraic formula just to be sure since Math can get confusing sometimes. Thanks! I did feel somewhat unsure andI did acknowledge that I could be wrong. Sorry for using up your time like this. Hehehe...
Alle Kommentare anzeigen