Kaveri - der Trinity Nachfolger

Leute ihr werdet euch doch eh nie einigen oder auch nur annähern, also was soll die ellenlange, ergebnislose Diskussion? :]
 
Das wundert mich garnicht da du ignorierst wie gut die Kerne ausgelastet werden und ob nicht andere Faktoren wie eine Speicherlastigkeit mit reinspielen.
Machen wir es uns doch einfach und bleiben bei dem gleichen oder vergleichbaren Aufgabengebiet. Cinebench rendert, Pov Ray ebenfalls.
Beim Cinebench ist der i7 fast 20% vorn, beim Pov Ray sind beide fast gleich auf.

Warum ist das wohl so oder willst du damit ausdrücken das ohnehin ein Großteil der Software Intel optimiert ist und es deshalb legitim wäre es auch bei einem Benchmark umzusetzen?


Leute, Renderer untereinander zu vergleichen kann schon gar nicht funktionieren, da die architekturspezifische Performance stark von der zu rendernden SZene abhängt. Der kompositorische Mix der Shader ist da ausschlaggebend, und der wird vom User bestimmt. Der Fx-8350 ist immer eine opportune Alternative zu Intel prä-Haswell gewesen. Mit Embree zog übrigens AVX in V-Ray mit ein - sponsort bei Intel ;) In V-Ray 3.0 ist AVX hoffentlich unabhängig implementiert worden.

http://forums.cgarchitect.com/73976-xeon-e3-1230v3-hasswell-impressive-vray-renderer.html
 
Ist aber immernoch besser als mit speicherlastigen Pack Programmen oder gar Verschlüsselungsprogrammen die eine spezielle Recheneinheit verwenden zu vergleichen. ;)

Steht ja auch im Heise Download Bereich das Embree auf die Intel Prozessoren optimiert wurde.
http://www.heise.de/download/embree-1183870.html
Unterm Strich ist es aber egal da wir nicht die Werte von diesen Programmen vergleichen. ;)

Das AVX nicht gerade eine Stärke der Bullis ist ist auch nichts neues, der Mix macht es ebend und wenn FMA ebenfalls genutzt wird sieht die Sache vielleicht wieder anders aus, zumindest bei den Modellen vor dem Haswell und genau darum geht es. Die Nutzung aktueller Features bei leistungshungrigen Programmen bei allen Prozessoren.
In dem Zusammenhang wäre es aber auch interessant wie solche Renderer z.B. auf HSA reagieren würden aber das ist vermutlich noch zu neu.
 
Macht im Mittel 17% Vorsprung für den 4770K. In Cinebench sinds 18%. Stark Intel optimiert.
Wie gesagt, nimm WinRAR heraus, weil der Test definitiv vermurkst ist, ein FX-8350 ist nicht langsamer als ein FX-8150, und du kommst auf die von mir erwähnten 16%. Das ist weniger als bei Cinebench.
 
Die Rechnung möcht ich gerne mal sehen. Wie gesagt die Anwendungen herausnehmen die augenscheinlich auf 1 oder 2 Threads laufen.

Cyberlink Media Espresso ~20% Vorsprung des 4770k
dbPowerramp 16 Dateien ~20%
Paint.net ~12%
Pov Ray ~ 3%
Truecrypt ~19%
Winrar ~ 30%
264HD Benchmark 1 ~24%
Test 2 ~ 6%

Wenn also in Cinebench das credo gilt, stark Intel Optimiert, gilt es ebenso für den ganzen Testparcours und damit wird es augenscheinlich zu einer ungültigen Aussage,zu einer Aussage die unglaubwürdig ist.

Cyberlink Media Espresso ist für einen fairen Vergleich mehr als Zweifelhaft. Es gibt kein Artikel der erläuert was dort für Berechnung genau stattfindet. Auf der HP sind sie bei Version 6.5 stehen geblieben und im Test wird Version 6.7 verwendet. Die wenigen Angaben die es gibt deuten auf eine sehr gute Intelunterstützung einschließlich Quick Sync hin, wärend selbst bei den Unterstützen Nvidia und AMD Grafikkarte die GPU Unterstützung nur für spezielle Funktionen verwendet. Sonstige Unterstützung ist nicht mit angegeben.

Wennn das Bild richtig ist dann benutzt dbPowerramp den lame encoder. Und dieser benutzt selbst in der Multikerne Version nur max 2 Kerne. http://www.deskmodder.de/phpBB3/viewtopic.php?f=123&t=14110 außerdem wurde er mit dem Intelcompiler hergestellt.

Was die bei 264HD Benchmark 1 vermessen haben ist mir unklar. Wenn es der Firstpass ist, dann wird wohl nur 1 Kern benutz werden. Auf Grund der bei dem angegeben Bild angegeben hohen Framerate konnen die auch nur die Übertragungsgeschwindigkeit des Speichers gemessen haben.
 
Leute ihr werdet euch doch eh nie einigen oder auch nur annähern, also was soll die ellenlange, ergebnislose Diskussion?

+1 zustimm
 
Da die Diskussion schon mitten in den Wirren von Testverfahren angelangt ist: abseits von AES liegt AMD bei den Verschlüsselungsalgorithmen Twofish und Serpent (wie auch Kombinationen) pro Modul recht eindeutig vorne, z.B.:
http://www.bjorn3d.com/2012/10/amd-fx-8350/7/
http://www.xbitlabs.com/articles/cpu/display/core-i7-4770k_9.html
Die Wahl des Verschlüsselungsalgorithmus mag zwar Geschmackssache sein, AES geht selbst ohne dedizierte Hardware etwas flotter zu Werke, aber gerade die Tatsache der höchsten Verbreitung erhöht schon wieder die Attraktivität und damit Wahrscheinlichkeit für die Ausnutzung potenzieller Schwächen. Wer paranoid genug ist, kümmert sich weniger um die Zeit- und oder Energie-Ersparnis bei der (De-)Chiffrierung als vielmehr um die erhöhte Sicherheit der Daten durch eine abseits des Mainstreams liegende Kombination der Verschlüsselungsalgorithmen. Insofern ist Truecrypt durch das Zweitkriterium (wie auch durch die höhere Performance bei z.B. Twofish) auch nicht gerade ein Paradebeispiel, um derartige Benchmark-Aussagen zu untermauern.

Damit mir der Hakenschlag zurück zum Thema noch gelingt: Es wird langsam Zeit für eine GPGPU-(d.h. HSA) Unterstützung in diesem Bereich.
 
Zuletzt bearbeitet:
gruffi schrieb:
Wie gesagt, nimm WinRAR heraus, weil der Test definitiv vermurkst ist, ein FX-8350 ist nicht langsamer als ein FX-8150, und du kommst auf die von mir erwähnten 16%. Das ist weniger als bei Cinebench.

Waurm sollte man zugunsten des FX immer irgendwelche Tests herausnehmen? Es gibt halt nunmal Tests die AMd und Intel besser liegen, das heißt noch lange nicht dass da was stark Intel optimiert ist, zumal zumal die Aussage noch mit keiner ernstzunehmenden Quelle verifiziert wurde.
Weise noch erst mal nach, dass dort zugunsten Intel optimiert ist.

Vielleicht ist ja Pov Ray für AMD optimiert?*buck*
 
Das AVX nicht gerade eine Stärke der Bullis ist ist auch nichts neues, der Mix macht es ebend und wenn FMA ebenfalls genutzt wird sieht die Sache vielleicht wieder anders aus, zumindest bei den Modellen vor dem Haswell und genau darum geht es. Die Nutzung aktueller Features bei leistungshungrigen Programmen bei allen Prozessoren.
In dem Zusammenhang wäre es aber auch interessant wie solche Renderer z.B. auf HSA reagieren würden aber das ist vermutlich noch zu neu.
Das kommt darauf an, wie man es sieht. Bei AVX lässt sich der FX-8350 auch mit 95W TDP spezifizieren.
Das haben sie aber nicht gemacht, da FMA4&XOP wohl der Burner sind! (220W TDP)
Interessant ist nun das selbst der Athlon 5350 FMA4 hat, das ist aber praktisch: CPU und GPU Teil haben den selben Befehlssatz. *suspect*
 
Wennn das Bild richtig ist dann benutzt dbPowerramp den lame encoder. Und dieser benutzt selbst in der Multikerne Version nur max 2 Kerne. http://www.deskmodder.de/phpBB3/viewtopic.php?f=123&t=14110 außerdem wurde er mit dem Intelcompiler hergestellt.
Er hat ja extra den Test mit 16 Dateien genommen. Auch wenn LAME lediglich singlethreaded ist (LAME MT ist dualthreaded), da sollten trotzdem bis zu 16 LAME Instanzen laufen bzw bis zu 16 Threads Last erzeugen. Das geht schon in Ordnung. Allerdings stellt das LAME Projekt lediglich den Quellcode bereit. Kompilieren muss man es schon noch selber. Und da gibt's halt mehrere Quellen, die verschiedene Binaries bereitstellen. Woher dbPowerramp genau seine Binaries bezieht, ist mir unklar. Entwickelt wurde das Projekt jedenfalls auch mit Microsoft Visual Studio samt Compiler. Für Codecs greift man aber wohl gerne auf Intel kompilierte Binaries zurück. Die auf der LAME Seite verlinkten RareWares Binaries sind zB mit Intel Compiler erstellt.


Waurm sollte man zugunsten des FX immer irgendwelche Tests herausnehmen?
Es wurden keine Tests zugunsten des FX rausgenommen. Wenn ein FX-8150 ein besseres Ergebnis liefert als ein FX-8350, dann kann man sich sicher sein, dass die Ergebnisse für die Katz sind. Und eine gewisse Konsistenz sollte schon vorhanden sein bei solchen Vergleichen. Die ist bei WinRAR einfach nicht gegeben. Da könnte ich jetzt zB auch auf den integrierten Test verweisen, wo es lediglich 13% Unterschied zum i7-4770K sind und der i7-3770K schneller ist als der i7-4770K. Du siehst also, die Ergebnisse sind nicht nur für AMD nicht zu gebrauchen, sondern für Intel genauso.

Weise noch erst mal nach, dass dort zugunsten Intel optimiert ist.
Es wurde hinlänglich bewiesen, dass Cinebench auf Intel optimiert ist. Damit solltest auch du dich langsam mal abfinden. Solch Sturheit ist echt nur noch peinlich.



Übrigens, LAME mit ICC 12.1 ist auf meinem X4 schneller als die aktuellere Version 14. ~34,7 play/CPU vs ~33,2 play/CPU bei einer knapp 50 MB grossen WAV Datei und VBR(q=2). So viel zum Intel Compiler und AMD. :]
 
Zuletzt bearbeitet:
Wenn ein FX-8150 ein besseres Ergebnis liefert als ein FX-8350, dann kann man sich sicher sein, dass die Ergebnisse für die Katz sind.

Der FX-8350 hat keine spürbare höhere IPC bei Anwendungen wie ein FX-8150.
Sieht man sich die Intel Prozessoren an, sieht es dort fast genauso aus, es sieht eindeutig so aus, als ob der Takt hier nicht limitieren würde, sondern etwas anderes.
Das ist kein Grund das Messergebnis herauszunehmen und selbst wenn, ändert das am Gesamtergebnis nichts.

Du siehst also, die Ergebnisse sind nicht nur für AMD nicht zu gebrauchen, sondern für Intel genauso.

Weil offenbar IPC und Takt diesen Benchmark nicht limitieren. Es gibt mehrere Benchmarks in denen Ivy vor Haswell liegt.

Es wurde hinlänglich bewiesen, dass Cinebench auf Intel optimiert ist.

Wo wurde das denn bewiesen? Wäre nett dies zu verlinken. Und ältere Version ausgenommen, um die geht es nicht.
Diese krude AMD Verteidigungshaltung von dir ist aber echt anstrengend.
 
Lasst's mal bitte gut sein, bevor ein Mod wieder aufräumen muss...
Den Beweis würde ich aber aus Interesse auch gerne sehen wollen.
Mir sind die Tricks bei CB10 (z.B. mit DLL File von R11.5 oder VM mit anderer CPU-Kennung) bekannt, aber von CB11.5 (und CB15) weiß ich nix bzw. kann ich auch auf die schnelle nichts finden. Weiß da jemand mehr (hat was handfestes)?
 
Dann muss aber CB11.5 auch Phenom optimiert sein, weil z.B. ein alter Phenom X4 980 unter MultiThreading über 32% schneller ist als ein neuerer A10 5800K +8% mehr Takt *buck*.

Das liegt ja wohl eher an der FlexFPU als an irgendetwas anderem. Bei INT-lastigem Code sieht das wieder ganz anders aus.
 
Weil offenbar IPC und Takt diesen Benchmark nicht limitieren.
Na das erkläre mir jetzt einmal ganz genau.
  1. Auf welche Weise kann eine IPC einen Benchmark "limitieren"
  2. Und auf welche Weise "limitiert" der Takt einen Benchmark?
Aber vielleicht bevorzugst du auch mal das Wort "Limit" in der Bedeutung zu googeln oder im Duden nachzuschlagen und beschließt etwas weniger Schwachfug zu verbreiten.

Den Beweis würde ich aber aus Interesse auch gerne sehen wollen.
2 Seiten vorher hier im Thread:
Hier haben offensichtlich einige Leute gar keine Ahnung was ein Compiler macht und warum hier der Intel Compiler zurecht kritisiert wird. Wer Cinebench für einen validen Benchmark hält, der sollte einiges an Basiswissen aufholen. Dies gilt auch für einige Redaktionen die sich mit Tests beschäftigen, wobei dort dieses Wissen üblicherweise vorhanden ist und dennoch ignoriert wird....warum das so ist kann sich jeder selber ausrechnen.

Wer sich informieren möchte und dann wieder in die Diskussion einsteigen will sollte hier lesen:
http://www.agner.org/optimize/blog/read.php?i=49#49
 
Der Beweis ist dass du einfach nicht alles liest. Lies dort die weiterführenden Links und Forenkommentare bis zu den weiteren Updates der Compiler....alles vorhanden.
Beispiel:
It's not getting better. The latest version of Intel's SVML (small vector math library) has some functions that can only be called from processors with AVX because the input parameter is an AVX vector (YMM register). There is no logical reason why these functions should have a CPU dispatcher, yet they have two different code paths for the same instruction set: An optimized version for Intel processors with AVX and an inferior version for other brands of CPU with AVX.
 
Der Beweis ist dass du einfach nicht alles liest. Lies dort die weiterführenden Links und Forenkommentare bis zu den weiteren Updates der Compiler....alles vorhanden.
Beispiel:

Ich versuche vergeblich den Teil zu finden, wo direkt auf CB11.5 / CB15 Bezug genommen wird.
Da helfen Kommentare über AVX-CodePaths wenig, wenn CB11.5 / CB15 nicht davon gebrauch machen, oder?
 
Du solltest dir vielleicht eine Quelle suchen die dir sagt welcher Compiler bei CB genutzt wird und nicht in der Quelle wo der Compiler an sich besprochen wird nach einer Endanwendung suchen. Du weisst doch was ein Compiler ist, oder? Die Quelle erklärt ausführlich wie die unterschiedlichen Vendorstrings zu unterschiedlichen Instruktionen führen.

Aber ich nehme dir die Arbeit für eine Quelle mal ab. Googles Trefferliste ist aber deutlich länger.
http://www.anandtech.com/show/5058/amds-opteron-interlagos-6200/10
Before we look at the Multi-threaded benchmark, Andreas Stiller, the legendary German C't Journalist ("Processor Whispers") sent me this comment:

"You should be aware that Cinebench 11.5 is using Intel openMP (libguide40.dll), which does not support AMD-NUMA"

So while Cinebench is a valid bench as quite a few people use the Intel OpenMP libraries, it is not representative of all render engines. In fact, Cinebench probably only represent the smaller part of the market that uses the Intel OpenMP API. On dual CPU systems, the Opteron machines run a bit slower than they should; on quad CPU systems, this lack of "AMD NUMA" awareness will have a larger impact.

We did not expect that the latest Opteron would outperform the previous one by a large margin. Cinebench is limited by SSE processing power. The ICC 11.0 compiler was the fastest compiler of its time for SSE/FP intensive software, even for the Opterons (up to 24% faster than the competing compilers), but it has no knowledge of newer architectures. And of course, the intel compiler does favor the Xeons.
 
Dann muss aber CB11.5 auch Phenom optimiert sein, weil z.B. ein alter Phenom X4 980 unter MultiThreading über 32% schneller ist als ein neuerer A10 5800K +8% mehr Takt.
Was hat denn das eine mit dem anderen zu tun? Überhaupt nichts. Ich habe ein und dieselbe CPU anhand zweier verschiedener Compilerversionen verglichen, du nicht. Cinebench ist wie gesagt mit dem ICC erstellt und damit vollständig auf Intel optimiert. Was AMD CPUs da machen, ist reines Glücksspiel. Die bekommen keine speziellen Optimierungen. Die bekommen maximal ein paar unnötige Hürden.

Du scheinst aber nicht so wirklich verstanden haben, was ich sagte. Du musst zwischen Intel Optimierung und absichtlicher AMD Beeinträchtigung des ICC differenzieren. Beides benachteiligt AMD in Reviews. Ich sprach allerdings lediglich über ersteres. Letzteres wurde hier ja schon mit genügend eindeutigen Quellen in der Vergangenheit belegt. Die aktuelle Situation dazu schaut eher undurchsichtig aus. Intel agiert da mittlerweile nicht mehr mit so plumpen Tricks wie der CPUID Herstellerkennung.


Der FX-8350 hat keine spürbare höhere IPC bei Anwendungen wie ein FX-8150.
Sieht man sich die Intel Prozessoren an, sieht es dort fast genauso aus, es sieht eindeutig so aus, als ob der Takt hier nicht limitieren würde, sondern etwas anderes.
Das ist kein Grund das Messergebnis herauszunehmen
Doch, ist es. Denn wenn die CPU nicht der alleinige ausschlaggebende Faktor ist, dann brauchen wir damit auch keine CPUs vergleichen. Dann mach daraus einen Speichervergleich, Mainboardvergleich, Festplattenvergleich oder was auch immer signifikanten Einfluss hat.

Wo wurde das denn bewiesen?
Wurde oft genug hier im Forum diskutiert. Einfach mal die Forensuche bemühen. Deine sture Scheuklappenhaltung ist aber echt anstrengend.
 
Die Frage ist doch mit welchem Compiler wird AMD schneller? Und warum sollte man ein Produkt (Intel) absichtlich mit einem schlechteren Compiler testen nur weil die Konkurrenz nicht konkurrenzfähig ist ;-).
Bei obigen lese ich zumindest heraus das es um Multi-CPU Unterstützung geht auch das muss Intel nicht für AMD richten.

Irgendwie erinnert mich das alles an Ken Olsen und da gab es die gute Software auch nicht von alleine.
http://www.heise.de/newsticker/meld...dware-hat-zum-Tode-von-Ken-Olsen-1185387.html
 
Die Frage ist doch mit welchem Compiler wird AMD schneller? Und warum sollte man ein Produkt (Intel) absichtlich mit einem schlechteren Compiler testen
Das verlangt doch gar keiner. Es wurde lediglich verlangt, dass man diese Sachen dann auch richtig einordnen und nicht zum alleinigen Maszstab hochstilisieren sollte, so wie das eben gerne mit Cinebench gemacht wird.
 
Ich klemm mal das Abo von dem Thread ab - um Kaveri geht es hier so gut wie gar nicht mehr. Winke
 
Zurück
Oben Unten