News Französische Seite testet 100 (!!) Prozessoren

Status
Für weitere Antworten geschlossen.
dermoritz schrieb:
o o, das ist vernichtend für amd - irgendwie find ich es komisch das meinn c2d 6750 vor allen amd (inkls quad) ist - mit gutem abstand.
man kann das natürlich relativieren, das offensichtlich die software im schnitt extrem schlecht auf viele kerne abgestimmt ist, aber es bleibt das problem, dass amd ganz miese leistung pro kern abliefert und das ist echt traurig :-(

aber nur in anwendungen, die nur 1-2 cores nutzen ...
 
Also das ist ja echt hammer!!! PC testes lessen und vergleichen cool

@ Alle cool 100Prozessoren getestet und es sind 100 Beiträg verfasst worden (ohne meinen)
 
@Zeiner-Rider: Zu SuperPi hat der CB user gruffi folgendes verfasst dass diese Software als Benchmark disqualifiziert:


Im planet3dnow Forum stand mal etwas interessantes dazu. AMD kann pro Takt 3 x87 FP Instruktionen verarbeiten. Der Maschinencode von Super Pi ist dafür aber nicht ausgelegt, weil er eben für die damaligen uneingeschränkt vorherrschenden Intel CPUs erstellt wurde. Man sollte nicht vergessen, Super Pi stammt aus dem Jahre 1995.
Ich kann dir nicht sagen, ob diese Analyse zutrifft, ist aber durchaus plausibel. Würde man den Super Pi Quellcode durch einen aktuellen Compiler jagen, der für AMD optimiert, wären auch hier bessere Zeiten zu erwarten. Trotzdem denke ich nicht, dass Core2 CPUs, zumindest was IPC betrifft, bei diser Anwendung übertroffen werden könnten.
Man sollte Super Pi daher nicht mehr für Leistungsvergleiche verwenden, schon gar nicht zwischen unterschiedlichen Herstellern. Selbst für ein und den selben Hersteller ist Super Pi nur noch begrenzt brauchbar, da eben nur obsolete x87 Instruktionen für FP genutzt werden. Aktuell ist jedoch SSE.
 
Plasma81 schrieb:
SuperPI passt allgemein kaum noch in die Heutige Zeit, da es auch noch ein einfaches Programm im Sinne von, es nutzt nur ein Kern, ist. Man kann zwar hier pro Kern die Leistungsfähigkeit ermitteln, aber es ist eben Alt.
Zudem bietet SuperPI genau so wie manche anderen, keinen wirklichen Vergleichstest, da es nur Theoretische Dinge sind, CineBench usw. sind für mich aussage Kräftiger als so ein theoretischer Test.

Zu dem Test selbst, wenn man es Geschickt anstellt kann man hier sicherlich optimierungen betreiben, dass es zwar Arbeit ist, aber nicht soviel Zeit verschlingt, wie hier erwähnt.
 
Zuletzt bearbeitet von einem Moderator:
Finde auch, dass Cinebench ein sehr guter Benchmark wäre, aber der wird aber leider viel zu selten eingesetzt.
 
Interessanter Test, allerdings wohl in 32bit oder? (Habe auch nach mehrmaligem durchsehen dazu nichts gefunden.) AMD schneidet ja ziemlich schlecht ab.

Allerdings kann ich die Ergebnisse nicht ganz bestätigen. Beim Rendern ist mein Phenom 9750 mehr als doppelt so schnell als mein E6600 in 64bit. (Software Blender 64bit und Indigo 64bit)
Aber ich werde da nochmal Benchmarks machen um das zu verifizieren.
 
Jetzt weiß ich was die Franzosen die letzten Jahre gemacht haben ;). Echt ein toller Test aber mit meinem Latein bin ich dann auch irgendwann am Ende.
 
Also danke für die Erklärung bezüglich SuperPi!

Wie wird mit Cinebench richtig gebencht? Mit dem Button "Rendering (x CPU)" ?
 
wenn man die Quadcores ausblendet ist der Test in Ordnung.

Zum Vergleich der Quadcores wären Quadcore optimierte Programme sinnvoll gewesen warum man nicht einen aktuellen x264 encoding benchmark nimmt? ist heutzutage jedenfalls standard.
und dort wird auch Leistung gebraucht.

die ganzen MPEG 4 ASP Encoderings bzw. MPEG2 übervorteilen nur die Dualcores.
 
Zeiner-Rider schrieb:
Wie wird mit Cinebench richtig gebencht? Mit dem Button "Rendering (x CPU)" ?

Genau, dann werden alle Kerne beansprucht.
 
Fairy Ultra schrieb:
Zum Vergleich der Quadcores wären Quadcore optimierte Programme sinnvoll gewesen
dann häte man nicht genug Programme für einen aussagekräftigen Test gehabt :evillol:

warum man nicht einen aktuellen x264 encoding benchmark nimmt? ist heutzutage jedenfalls standard...
Standard bei wem bzw. wo ?
Ich glaube, dass encoding mit xvid eher den Standard darstellt und das nutzt nichtmal meinen 2. core aus, im Gegensatz zu DivX welches hier getestet wurde und Quads übermäßig gut aussehen lässt.
Imo übervorteilt der Test also Multi-Core-CPUs wo es ein Single-Core in der Praxis auch tut (man sieht ja, dass selbst Crysis mit ner 5-Euro-bei-Ebay-CPU läuft)
 
Blutschlumpf schrieb:
Standard bei wem bzw. wo ?
Ich glaube, dass encoding mit xvid eher den Standard darstellt und das nutzt nichtmal meinen
Xvid wird in der Warez szene sicher öfter verwendet ;)
Dennoch ist h.264 Stand der Technik

2. core aus, im Gegensatz zu DivX welches hier getestet wurde und Quads übermäßig gut aussehen lässt.
Imo übervorteilt der Test also Multi-Core-CPUs wo es ein Single-Core in der Praxis auch tut (man sieht ja, dass selbst Crysis mit ner 5-Euro-bei-Ebay-CPU läuft)
nö divx lastet genauso wenig aus wie xvid. Bei Xvid profitieren nur die 45nm Prozessoren mit SS4 sehr gut.
CPUs ohne diesen Befehlssatz liegen auf dem niveau von dualcores.
Auch Xvid kann einigermaßen die gut noch 2 Kerne nutzen, mehr als 2 verpufft aber.
Die Auslastung ist hierbei nicht das Maß sondern die FPS mit der encodiert wird.
 
Fairy Ultra schrieb:
Xvid wird in der Warez szene sicher öfter verwendet ;)
Jupp, so ist es. In welcher "Szene" wird h.264 denn benutzt ? Ich bezweifle, dass die meisten @home HD-Videos rendern oder encoden werden, ich würde sogar vermuten, dass der Großteil der User sie nichtmal gucken kann, sei es mangels CPU-Power oder nem Bildschirm der groß genug ist. Für non-HD benutzt es vermutlich gar niemand.
Dennoch ist h.264 Stand der Technik
Stand der Technik vielleicht, aber nicht Standard. Der Maybach ist auch Stand der Technik, aber bestensfalls die C-Klasse würde noch unter "Standard" fallen


nö divx lastet genauso wenig aus wie xvid. Bei Xvid profitieren nur die 45nm Prozessoren mit SS4 sehr gut.
Dann erklär mir mal warum die 45nm Quads weit besser abscheiden als die 45er DCs ?
Beim Vergleich E8x00 gegen 65er Quads oder X4 mag SSE den Unterschied machen, aber die Q9xx0 profitieren da nicht weniger von als die DCs.

Auch Xvid kann einigermaßen die gut noch 2 Kerne nutzen, mehr als 2 verpufft aber.
Die Auslastung ist hierbei nicht das Maß sondern die FPS mit der encodiert wird.
Zumindest in der Kombination die ich hier benutze (VirtualDubMod + xvid 1.1.3-VAQ-27042008) profitiert es nicht vom 2. Core.
Die Auslastung verteilt sich zwar augenscheinlich, aber ich tippe mal da wechselt der Prozess nur von einer auf die andere CPU, nutzt aber nicht beide gleichzeitig.
Jedenfalls bringts keinen Performance-Vorteil, hab gerade mal ne Minute Film umgewandelt, die Ergebnisse von einem Core und 2 Cores waren auf die Sekunde genau identisch.
 
Blutschlumpf schrieb:
Jupp, so ist es. In welcher "Szene" wird h.264 denn benutzt ? Ich bezweifle, dass die meisten @home HD-Videos rendern oder encoden werden, ich würde sogar vermuten, dass der Großteil der User sie nichtmal gucken kann, sei es mangels CPU-Power oder nem Bildschirm der groß genug ist. Für non-HD benutzt es vermutlich gar niemand.

HD Encodes werden meist in h.264 gemacht.

Ist aber weniger verbreitet weil es natürlich wesentlich rechenintensiver ist und auch die Verbreitung von HD noch gering ist.
Aber auch für lowbit Encodes ist h.264 meist wesentlich besser wegen der besseren Bildqualität pro MB.

Xvid bleibt meistens nur die wahl weil es deutlich schneller ist, nur skalieren x264 encoder sehr gut mit takt und kernen und werden somit auch irgendwann xvid einholen, bei besserer Qualität.
 
Zuletzt bearbeitet:
Fairy Ultra schrieb:
Aber auch für lowbit Encodes ist h.264 meist wesentlich besser.
Glaubst du oder gibts da irgendwelche glaubwürdigen Vergleiche ? Da ich an keinem der beiden Codecs mitprogrammiere kann ich da nur vom Hörensagen ausgehen, dass xvid mit VAQ, QP, GMC h.264 absolut ebenwürdig ist. Wenn mans so encoded dass es auf dem DivX-kompatiblen DVD-Player anno 2005 fehlerfrei laufen soll, dann vermutlich nicht.

Xvid bleibt meistens nur die wahl weil es schneller ist
Sorry, aber bei non-HD den Rechenaufwand als Grund zu nennen während HD-Videos ja schon als 264 released werden, ist doch wohl ein schlechter Witz. Keine Gruppe die halbwegs was auf sich hält würde die Rechenzeit bei sowas beachten.
Mir fällt nur ein Grund ein warum DVD-Rips durchweg mit xvid und nicht mit DivX oder h.264 encoded werden: Es gibt keinen besseren für den Job.
nur skalieren x264 encoder perfekt mit takt und kernen und werden somit auch irgendwann xvid einholen.
Noch ein Grund warum der Rechenaufwand imo keinen Grund darstellt, dauert ja nicht länger, lastet nur mehr Cores dabei aus ;)
 
Zuletzt bearbeitet:
Blutschlumpf schrieb:
Glaubst du oder gibts da irgendwelche glaubwürdigen Vergleiche ? Da ich an keinem der beiden Codecs mitprogrammiere kann ich da nur vom Hörensagen ausgehen, dass xvid mit VAQ, QP, GMC h.264 absolut ebenwürdig ist. Wenn mans so encoded dass es auf dem DivX-kompatiblen DVD-Player anno 2005 fehlerfrei laufen soll, dann vermutlich nicht.
Ich betrachte natürlich immer die Effizienz hierbei.
also das h.264 weniger Platz braucht bzw. bei gleichem Platz besseres Bild liefert.

Spielt der Platz keine Rolle ist Xvid der Encoder der Wahl.
 
Fairy Ultra schrieb:
Ich betrachte natürlich immer die Effizienz hierbei.
also das h.264 weniger Platz braucht bzw. bei gleichem Platz besseres Bild liefert.
Das ist ja die Frage, gibts da brauchbare Werte wie viel Unterschied das ist bzw. obs da überhaupt noch Unterschiede gibt bzw. bei welchen Auflösungen ?
Ich hab z.B. gelesen, dass xvid alleine durch den Einsatz des (von h.264 portierten) VAQ ~10% weniger Daten bei gleicher Quali braucht.
 
respekt dem, der respekt verdient

danke CB, dass ihr die leistungen eurer kollegen anerkennt
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben