News AMD Piledriver vs. Steamroller vs. Excavator - Leistungsvergleich der Architekturen

[ONH]

Nun gerade beim Musik konvertieren ist es doch so, dass selten nur eine Datei konvertiert werden soll.
Mal abgesehen davon war es nicht beim neuen videostandard so dass man diesen von Grund auf für mehreren CPU ausgelegt wurde, weil gerade der Vorgänger schlecht zu parallelisieren ist.
Mp3 ist ja noch nicht für mehrere Kerne optimiert, wenn man sich anschaut aus welcher Zeit es stammt.

 

[hoschi_tux]

Ändert aber nichts an der Tatsache, dass 10 bis 20 Jahre Zeit war dafür, sich Gedanken darüber zu machen. Und sich jetzt hinzustellen und zu sagen, dass man adhoc keine Lösung hat, ist wie die Telekom die aktuell sagt, der Netzausbau ginge zu langsam voran.

 

[miriquidi]

Wenn du vor 10 Jahren einen parallelisierten MP3-Encoder entwickelt hättest, der, sagen wir mal, bis acht Threads gut skaliert, hättest du wenig Geld damit verdient. Aufgrund des aufgeblasenen Codes, die Parallelisierung kommt ja nicht von allein, wäre der Single-Threaded wohl auch noch langsamer gewesen und hätte evtl. den kleinen L1-Cache eines Pentium IV schnell gesprengt.
Abgesehen davon, dass du damals noch gar nicht über die Software-Infrastruktur verfügt hättest, die Parallelisierung selbst für Freizeit-Programmierer zugänglich macht.

 

[hoschi_tux]

Es geht nicht darum, vor 10 Jahren einen parallelisierten En-/Decoder auf den Markt zu bringen, sondern frühzeitig die Entwicklung dahin anzustoßen. Die Richtung in die es sich entwickelt war klar abzusehen, spätestens nach der gescheiterten Netburstarchitektur.

Dieses Problem lässt sich aber nicht nur an mp3s fest machen. Das betrifft die komplette Softwarelandschaft. OpenCl wird nur in homöopathischen Dosen genutzt, wo der eigentliche Implementierungsaufwand eher gering ist. Lieber verhält man sich passiv und wartet ab, bis neue SIMDs und Compilerunterstützung für nötigen Fortschritt sorgen.

 

[sompe]

@ miriquidi
Deine "weil is so" Begründung IST einfallslos. Ginge es darum würden wir heute noch auf den Bäumen hocken.
Nur weil sich im Bereich der Desktop Software keiner die Mühe macht heißt das noch lange nicht das es nicht möglich wäre. Vermutlich ist der Smartphone/Tablet Bereich bei der Hardware Ausnutzung schon deutlich weiter. Und wie di so beharrlich ignorierst betrifft das nicht nur die Multicore Unterstützung sondern auch erheblich die Unterstützung neuer Befehlserweiterungen und Funktionen.

Deine Rechtfertigung sehe ich mal als deutliches Beispiel für das Desinteresse an einer technischen Weiterentwicklung an.
Man holt raus was geht aber investiert nicht mehr. Dann kann man sich abseits von Steigerungen der Taktfrequenz auch die Weiterentwicklung der Prozessoren sparen und den Bereich ist mehr oder weniger tot.

 

[miriquidi]

Im Nachhinein ist immer alles klar abzusehen. Ich würde als Verantwortlicher in einer Softwarefirma jedenfalls keine Prognose zutrauen, wie die Computerrechentechnik in 10 Jahren aussieht, was dann angesagte Anwendungen sind und daraufhin Entwicklungsgeld in Vorlaufprojekte stecken, für deren Lösung es noch nicht mal ein Problem gibt.

 

[sompe]

Was hat das mit "im Nachhinein" zu tuen wenn die Multicore Prozessoren vor bei beiden großen Herstellern vor bereits 10 Jahre aufkamen und Multi Prozessor Systeme noch deutlich länger existieren? Du willst mir jetzt nicht ernsthaft sagen das die ganzen Programme über 10 Jahre Entwicklungsdauer hinter sich haben das es ach so schwer absehbar ist wo die Reise hin geht und es in der Zeit auch noch ach so unmöglich ist die Produkte in der Entwicklungszeit nochmal entsprechend anzupassen?
Dazu noch eine Abwartehaltung in einem so schnell lebigen Markt wie der Computer Industrie wo es für den Erfolg entscheidend ist am Anfang dabei zu sein?

Was du umschreibst ist für mich nichts anderes als desinteresse an der Weiterentwicklung und Investitionen aufgrund fehlenden Wettbewerbs.

 

[mulle]

Was du umschreibst ist für mich nichts anderes als desinteresse an der Weiterentwicklung und Investitionen aufgrund fehlenden Wettbewerbs.

Als "Verantwortlicher in einer Softwarefirma" muss ich miriquidi Recht geben. Die Kunden interessieren sich i.d.R. für *Features*; Performance ist *in der Regel* keines (da genügt 'ausreichend'). Und wenn die Entwickler-Stunde >100 EUR kostet, machst Du nix, aber auch gar nix, extra.

Im Gegenteil, Du nimmst Programmiersprachen wie C#, Python, etc. die - im Bezug auf die Maschine - einen Riesen-Overhead haben, Dich aber enorm Entwicklerzeit sparen. Den C - und Assemblerfuzzy gibt's nicht mehr in der bezahlten Entwicklung, die findest Du - vielleicht - noch an Hochschulen und bei Compilerbauern.

Wobei die interpretierten Sprachen den Vorteil haben, dass sie heutzutage auch später zur Laufzeit durch die JIT-Compiler der VMs optimiert werden.

 

[sompe]

Ich sprach nicht von assembler oder so sondern er.
Ich sprach nicht davon das max. an Performance rauszuholen sondern das vorhandene Hardware und CPU Features überhaupt genutzt wird.
Zudem kommt es auch darauf an um welche Software es geht. Ist sie Performance relevant oder nicht. Ist sie es nicht geht es wohl eher um Features weil man eh nicht merkt wie performant der Code ist. Wozu zählt dein Software Bereich?

Das die Performance aber keinen interessiert kann mir niemand sagen denn warum gibt es sonst die ewigen Benchmark/Hardware Diskussionen oder das Gejammer um die mangelhafte Leistungsentwicklung über die CPU Generationen hinweg?
Einfachstes Beispiel ist wohl das gemecker über Framerateneinbrüche durch CPU Limitierungen OBWOHL nur ein Bruchteil der CPU genutzt wird.

 

[mulle]

Ich sprach nicht davon das max. an Performance rauszuholen sondern das vorhandene Hardware und CPU Features überhaupt genutzt wird.

Eben. Das "Nutzen der Hardware- und CPU-Features" ist eben i.d.R. nicht damit getan, dass man ein paar Compiler-Flags umschaltet. Gerade bei AVX/SSE und Co. musste man die Codepfade i.d.R. manuell optimieren, und genau das zahlt Dir bei "normaler" Software genau niemand. Heute haben Compiler aufgeholt, aber nehmen wir mal an, Du setzt ein paar Flags anders. Dann musst Du damit rechnen, dass ggf. (je nach Verbreitung) deine Software auf manchen Kundenrechnern nicht mehr läuft. Also musst Du zur Laufzeit abfragen (und dann doch manuell verschiedene Codepfade einbauen) oder mehrere Versionen erstellen, pflegen und warten. Das kostet auch extra. Ergo: Der kleinste gemeinsame Nenner wird eingestellt, und wenn das (überspitzt) "486" heißt.

Das die Performance aber keinen interessiert kann mir niemand sagen denn warum gibt es sonst die ewigen Benchmark/Hardware Diskussionen oder das Gejammer um die mangelhafte Leistungsentwicklung über die CPU Generationen hinweg?

Games sind einerseits sehr speziell, andererseits aber auch ein gutes Beispiel: Die "eigentlichen" Game-Entwickler machen Grafik, Texturen und scripten Szenarios in der Skriptsprache einer Game-Engine (bei Unreal beispielsweise UScript oder neuerdings Visual Blueprints).

D.h. der weitaus größte Entwicklungsaufwand fällt *nicht* in die Kategorie "wir quetschen die Hardware aus". Low-Level-Optimierungen sind Sache der Engine-Entwickler oder ggf. auch ein Ding der "Gameworks" & Co. Spezialisten und das wird dann - sehr wahrscheinlich - nur punktuell an kritischen Stellen gemacht. Für den Rest gilt auch: "gut genug == fertig".

Was anderes ist bei kommerzieller Entwicklung nicht drin und gilt im Übrigen für alles in der Marktwirtschaft. "Optimale" Qualität bedeutet immer nur: Gerade gut *genug* - und kein bisschen mehr.

Zudem kommt es auch darauf an um welche Software es geht. Ist sie Performance relevant oder nicht. Ist sie es nicht geht es wohl eher um Features weil man eh nicht merkt wie performant der Code ist.

Das sage ich ja gerade. *Wenn* Performance relevant ist, dann wird optimiert, sonst nicht. Bei der überwiegenden Menge an SW zählen nur Entwicklungskosten und Features.

Wozu zählt dein Software Bereich?

Embedded. Und da ist es auch so: Wenn ein größeres SoC Entwicklerzeit spart, nimm das und fertig. Auf HW optimieren tut hier keiner, wir haben aber auch keine Millionen-Stückzahlen.

 

[sompe]

Da sind wir vielleicht schon bei dem Hauptproblem bei der Verständigung.
Embedded ist in meinen Augen schon ein recht spezieller Bereich wo die Auswahl an eingesetzter Software wohl recht speziell ist. Wenn man da einfach einen stärkeren SoC nehmen kann ist die Effizienz der Software wohl nicht sonderlich relevant.

Gerade im Spiele Bereich ist die Performance aber sehr wohl relevant und dennoch gibt es dort diverse Beispiele dafür das eben nicht entsprechend optimiert wird. Es gibt doch diverse Beispiele bei Strategiespielen wo selbst bei deutlich übertakteten Intel Prozessoren die Framerate stark einbricht, nicht zuletzt weil nur 1-2 Kerne genutzt werden. Wie effizient der Code mit den genutzten Kernen umgeht ist wieder ein anderes Thema.

Bei so ziemlich allen Programmen mit denen möglichst viel in einer möglichst kurzen Zeit berechnet werden soll ist dies ebenfalls relevant aber wieviele der Programme für den Desktop Bereich nutzen ernsthaft die Möglichkeiten der Prozessoren? Mir ist spontan so gut wie kein Programm bekannt das die Fähigkeiten moderner CPU Architekturen ernsthaft nutzt. Bestenfalls ist ne Multicore Unterstützung drin aber sonst?

 

[mulle]

Bei so ziemlich allen Programmen mit denen möglichst viel in einer möglichst kurzen Zeit berechnet werden soll ist dies ebenfalls relevant aber wieviele der Programme für den Desktop Bereich nutzen ernsthaft die Möglichkeiten der Prozessoren? Mir ist spontan so gut wie kein Programm bekannt das die Fähigkeiten moderner CPU Architekturen ernsthaft nutzt. Bestenfalls ist ne Multicore Unterstützung drin aber sonst?

Eben. Und aus den obigen ökonomischen Gründen wird sich dabei nix ändern; die meisten Spiele genauso, die werden ja auch so verkauft (ggf. Ausnahme die E-Sport-Geschichten und FPS). Wir sind einer Meinung, ich wollte Dir nur die Hoffnung nehmen, dass sich daran was ändert .

 

[WindHund]

Mir würde da nur der x264 Encoder einfallen, welcher in letzter Zeit die neuen Befehlssätze nutzt: http://abload.de/img/x264_stmt_hpc_3.0.1t7jnt.jpg

Beim testen von Windows 10 ist mir was aufgefallen, evt. erkennt jemand was ich meine: http://abload.de/img/avp1440pds-fx-9590-r710s1k.png
Das ist D3D11, kein Mantle oder DirectX 12.

 

[sompe]

@mulle
Dann sind wir aber wieder beim Punkt dass trotz Mehrwert eine technische Weiterentwicklung verweigert wird.

@WindHund
Hatten die nicht auch schon mit OpenCL rumprobiert? Schön zu sehen das sich zumindest einer Mühe gibt.

Meinst du die Reihenfolge der genutzten Kerne?
Sieht irgendwie so aus als würden die Kerne anders gezählt werden (erst physisch, dann logisch) oder der Shaduler wieder wie beim Erscheinen des FX arbeitet. (beide Kerne des Moduls nutzen, andere Module schlafen legen)

 

[WindHund]

@sompe
Ja, aber die openCL Implementation hat sich bei x264 nicht gelohnt, mal sehen wie es beim x265 Encoder aussieht.

Ja,die Kerne Parken nun in Gruppen 0-1, 2-3, 4-5, 6-7.
Sowie die sehr niedrige CPU Auslastung, hier mal mitgeloggt (AvP_Bench): http://abload.de/img/avp_esm_cpuusagejuppu.png
So schaut es bei Thief aus: http://abload.de/img/thief_ab_cpuusage3byf4.png

 

[sompe]

Nun ist gut, das war am Anfang bei dem Bulli auch so damit Core Parking die entsprechenden Module abschalten kann.
Später kam dann das Sheduler Update und behandelte die Module wie normale Kerne mit SMT.
Windows 10 scheint das bisher wieder so zu handhaben.

 

[WindHund]

Nun ist gut, das war am Anfang bei dem Bulli auch so damit Core Parking die entsprechenden Module abschalten kann.
Später kam dann das Sheduler Update und behandelte die Module wie normale Kerne mit SMT.
Windows 10 scheint das bisher wieder so zu handhaben.

Ich hatte das Sheduler Update nicht drauf mit Win 7, daher war es eher ein Durcheinander beim abschalten der Kerne.

Obwohl laut Park Control alle Kerne @ 100% sind, liegt die Auslastung pro Kern im Taskmanager unter 31% ?
http://abload.de/img/cpuz_bench_esm_multiekuxc.jpg

 

[sompe]

Hast du vielleicht ne Version wo das bereits mit drin ist? Das war kb2645594.
Park Control kenne ich nicht.

 

[WindHund]

Hast du vielleicht ne Version wo das bereits mit drin ist? Das war kb2645594.
Park Control kenne ich nicht.

Das erwähnte Update habe ich nicht gefunden unter Programme & Funktionen sowie im Update Verlauf in den Einstellungen.

Park Control ist von Bitsum, welche auch Process Lasso anbieten:

ParkControl is a small freeware utility that facilitates tweaking of core parking and CPU frequency scaling settings of Windows power plans. It has no installer. It is a live EXE.

https://bitsum.com/parkcontrol/
Bei Process Lasso ist es schon mit dabei, kann aber auch als Eigenständiges Tool herunter geladen werden.

Was ich bei der CPU Auslastung im Energiesparmodus nicht ganz verstehe, 100% Last werden erzeugt:
Win 7 alle Kerne @ 100% im Taskmanager (8x1.4GHz)
Win 10 alle Kerne @ 30% im Taskmanager (8x1.4GHz)

Wird hier nun auch die Taktfrequenz mit in die CPU Auslastung einkalkuliert?

 

[sompe]

Es kann natürlich auch sein dass das Update inzwischen in einem anderen Update aufgegangen ist, beispielsweise in einem Service Pack.
Ich weiss nur das sich mein FX nach der Windows Installation meiner alten Windows 7 Version ebenfalls so verhält und erst nach der Installation der Updates das SMT Schema befolgt.
Zu Parkcontrol.....vielleicht ließt es die Werte auch einfach nur falsch aus?

 

[WindHund]

Es kann natürlich auch sein dass das Update inzwischen in einem anderen Update aufgegangen ist, beispielsweise in einem Service Pack.
Ich weiss nur das sich mein FX nach der Windows Installation meiner alten Windows 7 Version ebenfalls so verhält und erst nach der Installation der Updates das SMT Schema befolgt.
Zu Parkcontrol.....vielleicht ließt es die Werte auch einfach nur falsch aus?

OK, ich steh gerade aufm Schlauch, was meinst du nun mit SMT Schema?

Bezüglich Auslastung, nein das scheint kein Auslesefehler zu sein, weil 1. Bei Prozesse die cpuz.exe (Multithread) ebenfalls nur 30% Auslastung erzeugt 2. mit Energieprofil Ausbalanciert 99% im Taskmanager anzeigt werden.

http://abload.de/img/fryrender_esmj3p8h.jpg

 

[sompe]

SMT Schema = erst alle Kerne mit einem Thread füllen bevor ein ein zweiter drauf kommt damit sich nicht beide gegenseitig behindern und bei der schlechten SMT Skalierung zu einem entsprechend grossen Leistungseinbruch kommt. Beim Bulli ist das eben auf das Modul bezogen.

 

[WindHund]

SMT Schema = erst alle Kerne mit einem Thread füllen bevor ein ein zweiter drauf kommt damit sich nicht beide gegenseitig behindern und bei der schlechten SMT Skalierung zu einem entsprechend grossen Leistungseinbruch kommt. Beim Bulli ist das eben auf das Modul bezogen.

OK, jetzt hat es klick gemacht.
Dem ist aber nicht so, die Last wird zuerst auf Kern 0-1 sowie 2-3 gelegt, wenn die Anwendung selbst keine Affinität festlegt.
Wenn man mit dem Mauszeiger über dem CPU Diagramm bleibt und die Maus nicht bewegt, wird eine kleine Info über die CPU Nummerierung sowie der Zusatz geparkt angezeigt.

 

[sompe]

Bei Windows 10, wo er offensichtlich wieder als normaler 8 Kerner behandelt, wo offensichtlich nicht zwischen den Kernen unterschieden wird aber schau dir mal an welche Kerne bei Windows 7 geparkt wurden.
Pro Modul ist dort nur ein Kern aktiv.

 

[WindHund]

Bei Windows 10, wo er offensichtlich wieder als normaler 8 Kerner behandelt, wo offensichtlich nicht zwischen den Kernen unterschieden wird aber schau dir mal an welche Kerne bei Windows 7 geparkt wurden.
Pro Modul ist dort nur ein Kern aktiv.

Ja, den Eindruck habe ich auch, die Skalierung scheint jedenfalls nicht darunter zu leiden.

Klar, Win 10 ist keine Lösung für alle Probleme, aber ich finde gefallen daran: http://abload.de/img/7zip_12tg4sd8.png