Kaveri - der Trinity Nachfolger

Cinebench berechnet Raytracing-Grafiken. Ist das für irgend jemanden relevant, außer den paar Leuten, die das Hobby-mäßig tun?
Und warum schneidet die gleiche CPU bei Cinebench deutlich besser ab, sobald sie sich als Intel-Prozessor ausgibt?

Es gibt zum Beispiel den PC-Mark, der mit echten Applikationen (Office, Adobe) arbeitet. Selbst wenn man die "Spar-Variante" (ohne echte Applikationen) nutzt: praxis-relevanter als Raytracing-Grafiken ist das auf jeden Fall!
 
Zuletzt bearbeitet:
Oder hat es mit den HP EliteBooks zu tun, dass die vorgestellt werden?
12, 14 und 15" FullHD Touchscreen hört sich nicht schlecht an.
http://m.hp.com/lamerica_nsc_carib/en/products/laptops/product-detail.do?oid=6732438
Mal gespannt, was in D ankommt.

Das ist echt mal eine Neuigkeit, wenn AMD es in die HP EliteBooks schafft.
Endlich ist zumindest bei einem OEM die Barriere von 1366x768 geknackt.
Eigentlich müssten EliteBooks auch mit mattem Display rauskommen, jedenfalls sollte die Marke das hergeben.
MfG
 
@derDruide

Ich finde PC-Mark auch besser aber an Cinebench kann man sehen ob die FPU besser geworden ist. Sobald ein Benchmark beliebt wird hat man immer das Intel-Problem allerdings wer lesen kann sollte das wissen. Besser als einem Benchmark die Schuld zu geben, wären halt Menschen die verstehen das man nur selten alles in 3 Zahlen packen kann. Würde auch im Finanzsektor einiges verbessern.

Ich persönlich fände jeweils FPU und INT Lastig einen Test sowie paar gemischte mit realen Applikationen 4-5 Spiele und dann noch so Sachen wie AES,OpenCL etc gut. Nur kommt dein Test dann vermutlich 5 Tage später als der Rest weil du gar nicht die Zeit bis zum Release hast. Dann hat man keine Klicks und bekommt beim nächsten mal kein Sample....
Aber die Wirtschaft will auch keine informierten Kunden die kaufen vermutlich wohl weniger.
 
Besser als einem Benchmark die Schuld zu geben, wären halt Menschen die verstehen das man nur selten alles in 3 Zahlen packen kann.

Wenn es um Dinge ginge, die man sich physisch vorstellen kann, würde ich dir Recht geben. Dann würde jeder sagen "was soll denn der Blödsinn?". Aber hier geht es um Dinge die man sich nicht vorstellen kann. Der Leser verlässt sich darauf dass ein professioneller Redakteur einer seriösen Seite schon die richtigen, Praxis-tauglichen Benchmarks raussuchen wird. Nur leider ist das nicht der Fall. Die Leser von Tests bestehen nicht nur aus P3D-Foren-Abonennten.

Ein erster Ansatz wäre ja schon mal, einen Benchmark mit echten Applikationen (wie den PC Mark) zu nehmen. Für die typische Ausrede, dass nicht jeder zu xx % Textverarbeitung macht, lautet die Antwort: Berechnet denn jeder zu 100 % Raytracing-Grafiken? Richtig ist, dass es nicht den perfekten Benchmark für alle Anwender gibt. Aber es gibt bessere und schlechtere Benchmarks. Für die besseren müsste man vielleicht etwas Arbeit investieren und ein Testsystem mit echten Programmen bereit halten.
 
Ein erster Ansatz wäre ja schon mal, einen Benchmark mit echten Applikationen (wie den PC Mark) zu nehmen. Für die typische Ausrede, dass nicht jeder zu xx % Textverarbeitung macht, lautet die Antwort: Berechnet denn jeder zu 100 % Raytracing-Grafiken? Richtig ist, dass es nicht den perfekten Benchmark für alle Anwender gibt. Aber es gibt bessere und schlechtere Benchmarks. Für die besseren müsste man vielleicht etwas Arbeit investieren und ein Testsystem mit echten Programmen bereit halten.

Für viele geht es ja schon zu weit sich zu überlegen was ein NB besitzer wohl mit seinem Gerät macht, wenn bei Desktops CB R15 verwendete wird kann man das ja noch einigermassen gerechtfertigen, aber kein normaler Mensch welcher auf Leistung angewiesen ist wird die Maxon Anwendungen wirklich auf einem Notebook laufen lassen.

Ich persönlich fände jeweils FPU und INT Lastig einen Test sowie paar gemischte mit realen Applikationen 4-5 Spiele und dann noch so Sachen wie AES,OpenCL etc gut. Nur kommt dein Test dann vermutlich 5 Tage später als der Rest weil du gar nicht die Zeit bis zum Release hast. Dann hat man keine Klicks und bekommt beim nächsten mal kein Sample....

Demnach müsste aber ein Notebooktest sich fast nur auf Browsertest, Flash/HTML5 Games und kleinere Bild-/Videobearbeitung konzentrieren, damit würde man wohl 80%+ abdecken und könnte auch die Testresultate gleichzeitig wie andere Redaktionen bringen, dazu noch 2-3 Sachen wie du genannt hast Testen und wenn es noch Zeit ist einwenig anspruchsvollere Tests machen und diese ev wie hier bei Mantle Test als Update bringen, dürfte doch die Klickzahlen der Tests in die Höhe Treiben, wenn mindestens die Stammkundschaft ein Review doppelt ansieht.
 
Vergess nicht einen Exceltest für Notebooks.
Bin immer am fluchen, wenn ich im Geschäft gigabytegroße Exceltabellen mit Bildern und Messdaten bearbeiten muß.
Das auf einer i5 Krücke mit 4GB RAM und ohne SSD. Flüssig arbeiten ist was anderes. Und die Bilddarstellung funktioniert dann auch nicht mehr einwandfrei.
 
Bei GB grossen Excel Tabellen würde man da nicht besser, auf 64bit Excel umsteigen, klar muss man da dann alle VB Tool umschreiben aber gross scheint mir der aufwand nicht zu sein. Wobei so grosse File auch schon wieder extrem Nischen sind... Mal abgesehen davon stell ich mir bei grossen Office Dateien mit Bilder immer die Frage ob es nicht übertrieben ist die Bilder in voller Auflösung reinzustellen 72dpi Bilder reichen meisstens.
 
Ich finde PC-Mark auch besser aber an Cinebench kann man sehen ob die FPU besser geworden ist.
Allerdings sollte man da trotzdem nicht zu viel reininterpretieren. Das letzte mal, als ich einen Profiler über Cinebench habe laufen lassen, hat der bezüglich FP quasi nur Operationen doppelter Genauigkeit ausgespuckt. Für den normalen Alltag oder auch für Spiele ist das wenig bedeutsam, da hier meistens FP Operationen einfacher Genauigkeit genutzt werden. Cinebench gibt halt lediglich die Performance eines 3D Renderers wieder. Und das stark für Intel optimiert. Mehr ist es nicht.
 
Bei GB grossen Excel Tabellen würde man da nicht besser, auf 64bit Excel umsteigen, klar muss man da dann alle VB Tool umschreiben aber gross scheint mir der aufwand nicht zu sein.
Lach. Sag das mal den Messtechnikern, die zwar ihr Oszilloskop wunderbar beherrschen, in der Lage sind super Messstände aufzubauen, auch noch in LabView die Programmierung derselben bewerkstelligen aber eben von Excel keine Ahnung haben.
Solange der Rechner noch zuckt, passt noch was in die Tabelle.
Hilfreich wären 16GByte Ram und SSD, aber wohl auch nur vorrübergehend bis der nächste Dr. Physik Abteilungsleiter verlangt, dass alle Messreihen zur statistischen Auswertung mindestens doppelt so oft durchzuführen sind. Auch sind es nicht nur die Bilder, die es zäh machen, sondern die Diagramme mit 500 Messreihen a 40000 Werten (Excel mekkert dann immer, das nur 32000 Werte in einem Diagramm dargestellt werden können) und davon dann mal eben 20 und mehr Diagramme in einem Document.
Und es sind nicht nur die 2000000 Messwerte sondern auch noch einige Millionen Zellen mit z.T umfangreicheren Formeln ausgefüllt.
Ich hab nicht grad die meiste Ahnung von Excel und Word, aber wenn ich seh wie unsere Ingenieure damit umgehen, verdreh ich als die Augen.
Natürlich wär eine angepasste Office Schulung sinnvoll, aber viel zu teuer. Von Ingenieuren erwartet man, dass sie sich das selbst beibringen. Die haben jedoch mehr als genug anderes um die Ohren um sich intensiver mit Office zu beschäftigen.
Und die alten VBA Anwendungen, die Praktikanten erstellt haben, rührt man am besten nicht an solange es funktioniert.
 
Solchen Datenmengen verlangen nach einer Datenbank.
 
Cinebench ist nicht nur praxisfern, sondern auch auf Intel optimiert. Schon zwei Gründe, warum dieser Benchmark nur eines aussagt: Nachts ist es kälter als draußen.
Dieses ewige Gejammer à la "Benchmark XY ist nicht relevant, weil mit Intelcompiler erstellt" geht mir ehrlich gesagt zunehmend auf die Nerven. Wenn du selbst Rechenalgorithmen schreiben oder intensiv nutzen müsstest, wüsstest du, wie hart 10 % Rechenzeitgewinn manchmal erarbeitet werden müssen. Das fällt nicht vom Himmel.
In der c't 12/14 ist ein Artikel ("Matrix reloaded") der sich mit Compilern am Beispiel der Matrixmultiplikation beschäftigt. Dort rechnet der Maschinencode aus Intels Composer 2013 mal eben um den Faktor 4 schneller als der von Microsofts Visual Studio und kam auf gut 50 % der theoretischen Spitzenleistung. Nutzen beiden nur nur klassisches SSE (kein AVX & FMA) liegt der Composer immer noch gut 50 % vor Visual Studio. Bei meinem Nachprogrammierversuch mit dem GNU C-Compiler schaffte ich es, ganze 2% des Rechenpotentials meines Chips zu nutzen.

Wenn dir das mit Cinebench nicht passt, dann werde konstruktiv und baue dir ein eigenes leicht bedienbares Benchmark und verbreite es. Das bringt tolle Einsichten und holt einen auf den Boden zurück. Ich simuliere grade mit einer kommerziellen Ingenieurssoftware und da rechnet ein Sandybridge Doppelkern im Notebook fast so schnell wie ein FX8350 oder ein Acht-Kern K10. Obwohl es kein Problem ist, acht Kerne permanent auszulasten.
Der Hersteller könnte vielleicht auch statt der Intel Mathe-Bibo eine GNU Bibo nutzen. Nur geht der Kunde zur Konkurrenz, wenn man statt 10 h eine ganze Woche verdaddelt.
Insofern spare dir diesen ständigen Verweis auf den Intel-Compiler - sie sind schlichtweg Industriestandard - und das zu recht. Abseits von Numa-Systemen ist er auch für einen AMD-Prozessor in der Regel immer noch die beste Wahl.
 
Wenn das selbe Stück Silizium allein dadurch schneller wird, weil es sich als Intel-CPU ausgibt, dann stinkt das. Egal wie gut oder schlecht der Intel-Compiler ist, zeigt dieses Beispiel, dass er die Konkurrenz gezielt benachteiligt. Cinebench wird aber immer wieder für Vergleiche zwischen Intel und AMD herangezogen.

Und ich habe schon einen konstruktiven Vorschlag gemacht, der das zweite Problem des weltfremden Workloads angeht. Einfach die Raytracing-Grafiken weglassen, die niemand zu Hause (oder in der Firma) berechnet, dann wären wir schon weiter.
 
Zuletzt bearbeitet:
Hallo

Ich simuliere grade mit einer kommerziellen Ingenieurssoftware und da rechnet ein Sandybridge Doppelkern im Notebook fast so schnell wie ein FX8350 oder ein Acht-Kern K10

Das möchte ich gerne sehen.
Welche Software hat solche Differenzen in der Geschwindigkeit ?

MfG
RedBaron
 
Zuletzt bearbeitet:
Natürlich wär eine angepasste Office Schulung sinnvoll, aber viel zu teuer. Von Ingenieuren erwartet man, dass sie sich das selbst beibringen. Die haben jedoch mehr als genug anderes um die Ohren um sich intensiver mit Office zu beschäftigen.
Und die alten VBA Anwendungen, die Praktikanten erstellt haben, rührt man am besten nicht an solange es funktioniert.

Ist so nur denkt man sich mal das unternehmen würde den Ingenieueren ein Tag ein Excel pro nebenherstllen dan würden die über längere Zeit (Jahr) ein vielfaches davon einsparen.
Zudem ist das nicht endkundenrelevant eine Firma muss immer ihre Tools auf der neuen HW Testen, bei Privatkunden kann man davon nicht ausgehen das er vor dem benutzen Testen kann.
 
derDruide schrieb:
Cinebench ist nicht nur praxisfern, sondern auch auf Intel optimiert. Schon zwei Gründe, warum dieser Benchmark nur eines aussagt: Nachts ist es kälter als draußen.

Cinebench ist sicherlich praxisfern, man kann aber jede Software oder jeglichen anderen Benchmarks genauso charakterisieren.
Welche Software ist nun geeignet?

Tatsache ist, dass Cinbenech die Anwendungsperformance im schnitt sehr gut abbildet und es ist auch so dass gerade in diesem Benchmark die FX Prozessoren noch am besten wegkommen.
Klickt euch mal bei Anandtech, Tomshardware oder Computerbase durch, stark Intel optimiert? Wohl kaum.

Andere Software muss ja dann extrem für Intel optimiert sein, wenn man der Argumentation weiter folgt.

miriquidi schrieb:
Dieses ewige Gejammer à la "Benchmark XY ist nicht relevant, weil mit Intelcompiler erstellt" geht mir ehrlich gesagt zunehmend auf die Nerven.

Es ist eine Art Reflex die schlechte Leistung von AMD Prozessoren zu relativieren.
Und gerade Cinebench wo AMD noch am besten liegt, als stark Intel optimiert zu beschreiben, ist aus der Luft gegriffen.

Wenn man schon einen Benchmark für ungeeignet hält, dann sollte man auch nicht zögern einige zu nennen die geeignet sind.
 
Zuletzt bearbeitet:
Dieses ewige Gejammer à la "Benchmark XY ist nicht relevant, weil mit Intelcompiler erstellt" geht mir ehrlich gesagt zunehmend auf die Nerven. Wenn du selbst Rechenalgorithmen schreiben oder intensiv nutzen müsstest, wüsstest du, wie hart 10 % Rechenzeitgewinn manchmal erarbeitet werden müssen. Das fällt nicht vom Himmel.
In der c't 12/14 ist ein Artikel ("Matrix reloaded") der sich mit Compilern am Beispiel der Matrixmultiplikation beschäftigt. Dort rechnet der Maschinencode aus Intels Composer 2013 mal eben um den Faktor 4 schneller als der von Microsofts Visual Studio und kam auf gut 50 % der theoretischen Spitzenleistung. Nutzen beiden nur nur klassisches SSE (kein AVX & FMA) liegt der Composer immer noch gut 50 % vor Visual Studio. Bei meinem Nachprogrammierversuch mit dem GNU C-Compiler schaffte ich es, ganze 2% des Rechenpotentials meines Chips zu nutzen.
Die gut 2% kann ich durchaus bestätigen anhand einer simplen Matrixmultiplikation mittels GCC 4.8.2. Allerdings solltest du bedenken, viel mehr würdest du mit dem ICC da auch nicht schaffen. Solche "Nachprogrammierversuche" kannst du nicht einfach so mit anderen Tests vergleichen. Vermutlich nutzt die c't MKL oder andere spezifische Mathebibliotheken. Das sind handgetunte hochoptimierte Bibliotheken, extra ausgelegt auf solche Berechnungen. Anders kannst du gar nicht auf 50% des theoretischen Durchsatzes kommen. Das hat herzlich wenig mit der eigentlichen Codegenerierung des Compilers zu tun. GCC ist schon relativ gut. Der unterstützt seit einigen Versionen ebenfalls Auto-Vectorization, was gerade solche Berechnungen enorm beschleunigen kann. Allerdings bringt der auch wesentlich mehr Einstellungsmöglichkeiten als andere Compiler mit, da viel mehr Architekturen unterstützt werden. Man muss also schon wissen, was man tut und die richtigen Flags setzen, damit entsprechende Optimierungen greifen. Der Code selbst ist ebenfalls wichtig. Einen interessanten Artikel dazu gibt's hier. Einen Vergleich zwischen GCC und ICC gibt's hier. Fazit, lediglich 30% Unterschied. Also wenn du mit GCC auf 2% des theoretischen Durchsatzes kommst, liegst du mit ICC immer noch bei 2,...%. MSC generiert übrigens deutlich langsameren Code als beide. So oder so wird das allerdings immer unwichtiger. Der Trend hier geht klar Richtung GPU bzw HSA.

sie sind schlichtweg Industriestandard
Nicht wirklich. Industriestandard unter Unix Systemen ist immer noch GCC, Industriestandard unter Windows ist MSC. ICC ist und bleibt zum Glück lediglich ein Nischenprodukt.


Tatsache ist, dass Cinbenech die Anwendungsperformance im schnitt sehr gut abbildet und es ist auch so dass gerade in diesem Benchmark die FX Prozessoren noch am besten wegkommen.
Nein und nein. Wie gesagt, Cinebench gibt hauptsächlich DP FP Performance wieder. Das hat für den durchschnittlichen Alltag herzlich wenig Bedeutung. Und am besten kommt da gar nichts weg. Du kannst dir ja mal Reviews wie auf Computerbase angucken. Gemittelt über Single- und Multi-CPU liegt ein i7-4770K fast 40% vor dem FX-8350 in Cinebench. Im Schnitt sind es in Anwendungen aber nur etwa 20%.
 
@RedBaron: Du hast Post.

Wenn das selbe Stück Silizium allein dadurch schneller wird, weil es sich als Intel-CPU ausgibt, dann stinkt das. Egal wie gut oder schlecht der Intel-Compiler ist, zeigt dieses Beispiel, dass er die Konkurrenz gezielt benachteiligt. Cinebench wird aber immer wieder für Vergleiche zwischen Intel und AMD herangezogen.
Ich suche immer noch den Beweis z.B. für das relative neue CB R11.5. Bei R10 gab' es sowas, das stimmt.

Und ich habe schon einen konstruktiven Vorschlag gemacht, der das zweite Problem des weltfremden Workloads angeht. Einfach die Raytracing-Grafiken weglassen, die niemand zu Hause (oder in der Firma) berechnet, dann wären wir schon weiter.
Wir messen dann demnächst die Seitenaufbauzeit beim Aufruf von faz.de. :)
Die Fixierung auf Raytracer ist wohl historisch gewachsen. Es war die erste Applikation, die man einfach ausführen konnte und sich gut parallelisieren ließ.

Die gut 2% kann ich durchaus bestätigen anhand einer simplen Matrixmultiplikation mittels GCC 4.8.2. Allerdings solltest du bedenken, viel mehr würdest du mit dem ICC da auch nicht schaffen. Solche "Nachprogrammierversuche" kannst du nicht einfach so mit anderen Tests vergleichen. Vermutlich nutzt die c't MKL oder andere spezifische Mathebibliotheken. Das sind handgetunte hochoptimierte Bibliotheken, extra ausgelegt auf solche Berechnungen. Anders kannst du gar nicht auf 50% des theoretischen Durchsatzes kommen.
Herr Stiller beschreibt die Compiler-Funktion als "Autobibliothekisierung". Den Compiler füttert man mit dem normalen c-Code, die Mathebibliotheken bindet Composer automatisch ein. Das ist toll. Wenn's dann wirklich ans Eingemachte mit Tagen und Wochen Rechenzeit geht, macht sich das ganz nett.

Nein und nein. Wie gesagt, Cinebench gibt hauptsächlich DP FP Performance wieder. Das hat für den durchschnittlichen Alltag herzlich wenig Bedeutung. Und am besten kommt da gar nichts weg. Du kannst dir ja mal Reviews wie auf Computerbase angucken. Gemittelt über Single- und Multi-CPU liegt ein i7-4770K fast 40% vor dem FX-8350 in Cinebench. Im Schnitt sind es in Anwendungen aber nur etwa 20%.
Hoffe der Link geht. Single-Threaded ist der i7-4770K 60%, Multi-Threaded ca. 20 % schneller als der FX8350.
http://www.computerbase.de/2013-09/intel-core-i7-4960x-test/4/#diagramm-cinebench-r115
Halte ich für ganz realistisch.
 
Müsste der fx nicht singlethreaded etwas besser da stehen? Die flex-FPU steht ja dann nur einem Kern zur Verfügung. Gerade wenn CB. So stark FP lästig sein soll. Zum testen könnte man ja mal CB auf einem Modul gegen ein Kern laufen lassen. Theoretisch sollte das ganze ja deutlich <80% skalieren wenn die FPU richtig unterstützt wird.
 
Single-Threaded ist der i7-4770K 60%, Multi-Threaded ca. 20 % schneller als der FX8350.

Halte ich für ganz realistisch.

Kaum.

Auf Phoronix finde ich mit Leichtigkeit Benchmarks, bei denen der FX zum Teil deutlich vor der Intel-Konkurrenz liegt. Als Beispiel hier nur C-Ray und John the Ripper, dort schafft es der FX 8350 sogar, einem übertakteten(!) I7-4960X die Rücklichter zu zeigen.
 
unl34shed: Ab vier Threads sollte die Skalierung mit dem FX schlechter werden, weil nur eine FPU pro Modul da ist. Beim i7 skaliert es aber noch schlechter, weil dort ab dem fünften Thread keine zusätzlichen Hardware-Ressourcen mehr zur Verfügung stehen, aber pro Thread nur noch die Hälfte an Cache zur Verfügung steht.

@Marodeur3D: Was sagt das schon? Es geht auch anders rum. Siehe "3D Particle Movement: Multithreaded" - ein 10 W Atom schlägt das Trinity Topmodell mit ca. 100 W Verbrauch:
http://www.anandtech.com/show/8067/...athlon-53505150-and-sempron-38502650-tested/4
Aber du kannst auch gerne mit C-Ray deinen Vergleich Kaveri-Mobil vs. Haswell-Mobil machen. *g*
 
@mirquidi
Warum wundert es mich jetzt nicht, dass auf einmal auch andere Benchmarks wichtig sind? Du schreibst, es geht auch anders rum und hast damit zumindest diesen Teil meines Posts verstanden. Aber den tieferen Sinn dahinter ganz offensichtlich nicht, denn es ging mir darum, zu zeigen, dass das Ergebnis eines einzigen Benchmarks allerhöchstens für die Statistik gut ist, für eine Performanceeinschätzung ala 60% Single-Threaded, 20% Multi-Threaded, wie du sie da von dir gegeben hast, aber in keinem Fall. Eine derartige Einschätzung sollte jeder für sich selbst an Hand seiner verwendeten Programme erstellen. Wer so etwas aber nur auf Basis eines einzigen Benchmarks macht, ist selber schuld.

Siehe "3D Particle Movement: Multithreaded" - ein 10 W Atom schlägt das Trinity Topmodell mit ca. 100 W Verbrauch
Und der Atom C2750 schlägt den I5-4690, womit über diesen Test wohl alles gesagt wäre, oder?

Und sobald ich einen Mobil-Kaveri in die Finger kriege, sag ich Bescheid, das wird allerdings ziemlich lange dauern, da meine Kasse z.Z. leer ist :)
 
Herr Stiller beschreibt die Compiler-Funktion als "Autobibliothekisierung". Den Compiler füttert man mit dem normalen c-Code, die Mathebibliotheken bindet Composer automatisch ein.
Hatte ich mir schon gedacht. Wie gesagt, das hat mit der eigentlichen Codegenerierung des Compilers nichts zu tun. Das ist halt sehr spezifisch und funktioniert auch nicht einfach so mit ISO C/C++ Code. Dafür musst du deinen Code anpassen und entsprechende Funktionen der Bibliotheken einbinden. Kannst dir ja mal ein Tutorial dazu anschauen. Hier kannst dir auch mal den vom ICC 13 generierten Assemblercode deiner Nachprogrammierversuche anschauen. Auch mit -mkl Flag wird da kein MKL Code generiert, wenn du eben nicht auch MKL Funktionen explizit verwendest. ICC ist da nix spezielles. Auch andere Compiler können Mathebibliotheken für Vektoroperationen auf diese Weise einbinden. Der einzige Unterschied mag vielleicht sein, dass man die Bibliothek zusätzlich installieren muss und der Compiler kein spezielles Flag dafür mitbringt, so dass man dem Linker die Bibliothek explizit mitgeben muss. Aber, who cares? Das sind Brot und Butter Arbeiten eines Entwicklers und macht im Endeffekt keinen Unterschied.

Hoffe der Link geht. Single-Threaded ist der i7-4770K 60%, Multi-Threaded ca. 20 % schneller als der FX8350.
http://www.computerbase.de/2013-09/intel-core-i7-4960x-test/4/#diagramm-cinebench-r115
Halte ich für ganz realistisch.
Realistisch für was? Der FX hat über 10% Taktvorteil und trotzdem liegt der i7 singlethreaded 60% vorne. Das ist im Schnitt sicherlich nicht realistisch. Und multithreaded gibt es genügend Beispiele, wo ein FX auch näher am i7 liegt. Wie gesagt, schau dir das Anwendungsrating an. Das soll ja einen Schnitt über verschiedene Workloads und Auslastungen abbilden. Da sind es lediglich 20% und keine 40%.

@Marodeur3D: Was sagt das schon? Es geht auch anders rum. Siehe "3D Particle Movement: Multithreaded" - ein 10 W Atom schlägt das Trinity Topmodell mit ca. 100 W Verbrauch
Trinity ist ja auch so aktuell. Und in CompuBench CL liegt ein 45W Kaveri etwa Faktor 8 bis 17 vor dem Atom. Da weiss man auch, wo die TDP von 10W herkommt. ;) Wir wollen doch mal realistisch bleiben. Extrembeispiele kann man sich immer rauspicken. Unterm Strich muss man einfach zugeben, dass Cinebench nicht wirklich aussagekräftig für den Alltag ist. Ist ja in Ordnung, wenn dir die ICC Thematik auf den Keks geht. Genauso nervig ist es aber, wenn immer wieder AMD vs Intel Vergleiche anhand solcher belanglosen Benchmarks hochstilisiert werden.
 
Trinity ist ja auch so aktuell. Und in CompuBench CL liegt ein 45W Kaveri etwa Faktor 8 bis 17 vor dem Atom. Da weiss man auch, wo die TDP von 10W herkommt. ;) Wir wollen doch mal realistisch bleiben. Extrembeispiele kann man sich immer rauspicken. Unterm Strich muss man einfach zugeben, dass Cinebench nicht wirklich aussagekräftig für den Alltag ist. Ist ja in Ordnung, wenn dir die ICC Thematik auf den Keks geht. Genauso nervig ist es aber, wenn immer wieder AMD vs Intel Vergleiche anhand solcher belanglosen Benchmarks hochstilisiert werden.
Vorallem wenn es am Thema vorbeigeht *buck* - es ging doch um die IPC der CPU, und nicht GPU (CompuBench CL läuft doch @GPU), oder? :)
 
Edit: For those wondering why AMD doesn't score so high... AMD architecture loves integer (whole number) operations, especially when parallel. This benchmark was written in floating point (FP) operations, which is the usual standard for scientific programming depending on the algorithm.
At PJs request I attempted to make a version more memory dependant, but the nature of these algorithms is such that they are best ported to GPU. So GPU version inbound soon, using C++ AMP to make it vendor agnostic.

Ich bin mal so frei den Autor von 3D Particle Movement Zu zitieren ohne ihn zu verlinken. Der Benchmark gehört an die gleiche Stelle, wo SuperPi hingehört.
Das Ding ist erstens nicht optimiert über das hinaus, was der Compiler macht und vom Algorithmus her weniger geeignet für eine CPU ist. Mehr gibt es dazu nicht zu sagen.
 
Ich bin mal so frei den Autor von 3D Particle Movement Zu zitieren ohne ihn zu verlinken. Der Benchmark gehört an die gleiche Stelle, wo SuperPi hingehört.
Das Ding ist erstens nicht optimiert über das hinaus, was der Compiler macht und vom Algorithmus her weniger geeignet für eine CPU ist. Mehr gibt es dazu nicht zu sagen.

SuperPi ist SingleThread und passt in den Cache.
3D Particle Movement ist MultiThreaded und nutzt überwiegend Floats... und weswegen ist es jetzt nicht für eine CPU geeignet?
 
Zurück
Oben Unten