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

Wir sind ja schon lange in dem Bereich wo Hardware durch Software künstlich beschnitten wird. Sowas nennt man dann Geschäftsmodelle.

Was ich mich frage wieweit es AMD frei steht zu entwickeln, oder an was für Verträge und Vereinbarungen der x86 Bereich gebunden ist. Ich weiß jetzt nur das Bill Gates einen Vertrag auf Lebenszeit hat, in der Verbindung mit IBM´s Patenten und LIzenzvergaben.

Wäre mal interessant wie das alles geregelt ist.
 
Im Bereich der Befehlssätze haben sie doch bereits einiges entwickelt und das sie bei der Architektur auch andere Wege gehen können sieht man ja beim Bulli aber es wurde von der Software Industrie nahezu alles ignoriert.
Das einzige was sich durchgesetzt hat war die 64 Bit Erweiterung und das auch nur weil Intel ihre Itanium Schiene Markt drücken wollte, mit entsprechenden Nachteilen bei der Kompatibilität und der Leistung bei der Bestandssoftware. Es war einfach das kleinere Übel weil man so gut wie nichts ändern mußte. Das sieht man ja auch an der extrem schleppenden Einführung bzw. dem Mangel an 64 Bit Software.

--- Update ---

@ONH
Du findest es ernsthaft toll wenn die Berechnung länger dauert als nötig?
Wenn das Startmenü unübersichtlicher ist als bei Windows 7, warum sollte ich dann die anderen Nachteile auch noch in Kauf nehmen und wechseln?

Windows 10 kann man mir genau so wenig schön reden wie Windows 8.
 
Nun in vielen fällen ist die Dauer nicht so relevant wie immervermittelt werden soll. Wenn kein des hw vorhanden ist für die Berechnung, ist IMHO eine Vollauslastung 100% der möglichen thread unproduktiver, der ma wartet dann 20min aud ein Resultat, anstelle von 40min auf das Ergebnis warten bei nur wobei er im 2. Fall andere Aufgaben erledigt.
Ist die Dauer einer Berechnung wirklich relevant, wird diese auf einem Server/es eines in den Ferien befindlichen Mitarbeiter ausgelagert, wenn die SW das Vollauslastung der CPU/GPU beherrscht.

Ist sind nicht 2 Maschinen pro Nutzer vorhanden.
Mal abgesehen bezweifle ich das wirklich zeitkritische heutzutage zuwenig St besitzt, es mag da kleine Ausnahmen geben, nur ist es für viele irrelevant.

Optik ist imhor irrelevant, wer auf verschachtelte menü steht soll dd bleiben, langfristig setzt sich icons durch, und das je mehr 90er Generationen in den Arbeitsprozess kommen. Startmenü pflegt man eh wenn man effektiv arbeiten will.
 
Guter Artikel, da sieht man welche Fortschritte man mit faktisch der gleichen Fertigungstechnologie machen kann.
Stark von AMD. Schade, dass sie diese Kerne nicht auch in Servern und AM3 einsetzen.

Die Behandlung von AM3+ ist sowieso ein Schandfanal für AMD 8-(
Ist ja in Ordnung, wenn die befinden auf der Plattform können/bzw. wollen wir Nix mehr reissen....
Aber das dann bitte (nach Möglichkeit mit Ausblick) offen kommunizieren!
Es reisst ihnen wohl auch Keiner den Kopf ab, wenn die offen bekennen den Sektor 15-20Monate unbesetzt zu lassen.
Allerdings wäre für AM3+ wöhl eher Steamroller Waffe der Wahl ;) und damit hätten sie was stemmen können, statt dem AMD FX-8350 ein Dreimoduler der die gleiche Multicoreleistung bei 80Watt anreicht und dazu einen Viermoduler, der bei 125Watt die Centurion eindampft , hätten womöglich ein paar Käufer gefunden..... :-*
Um mit Carrizo dick aufzufahren , müsste es schon ein Sechsmoduler sein. :]

Was ich aber gerne sehen würde, wäre nach Brazzostradition ein bestücktes Brett in Stile des KBN/I-5200 für kleines Geld und zwar mit dem Excavatorkern 8)
Den A10-8700P auf 25Watt , das dürfte wohl das Fundament für den idealen HTPC darstellen *clap*

Mmoe
 
@ miriquidi
Nein und viele von denjenigen die es können müßten offenbar auch nicht.
Ich sehe bei dir ausschließlich Gründe sich vor der MT Programmierung zu drücken aber auch keinen Grund warum neuere, leistungsfähigere Befehlssätze ignoriert werden.
Für Ärzte wäre es sicherlich auch viel einfacher auf dem Wisse zu verharren das sie bei ihrer Ausbildung erlernt haben aber nein.....stetige Weiterbildung ist da praktisch Pflicht.
Sofern du parallelisierst, obwohl es die Punkte a) bis c) (und d) von mariahellwig) nicht erfüllt, hast du eine Menge Arbeit ohne wirklichen Erfolg. In der Praxis äußert sich das z.B. darin, dass du mit acht Kernen gegenüber einem Rechenkern die Rechengeschwindigkeit verdoppelst.

Das beste Beispiel für die Ignoranz in diesem Bereich sind doch Audio Converter. Warum zum Henker bestehen so viele darauf die Liste nach und nach abzuarbeiten anstatt sie auf die Kerne zu verteilen? Und das ist wohl die primitivste Form die Kerne auszulasten. Ich kann mir gut vorstellen das ein ähnliches Vorgehen auch bei Spielen möglich wäre.
Parallele Audio-Encoder gibt es, ist auch nicht schwer so etwas zu schreiben. Bei 12 Kernen brauchst du aber eben auch 12 in etwa gleich große Audiodateien und du musst vorher wissen, wie aufwändig jede Kompression ist (was u.a. vom Dateiinhalt abhängt). Hast du 13 gleichaufwändige Dateien, könnte man 13 Threads auf 12 Kernen starten und immer mal einen anderen anhalten. Hast in der CD einen Track der sehr viel länger als alle anderen ist, bricht die Parallelisierung zusammen. Am Amdahlschen Gesetz kommst du einfach nicht vorbei.
https://de.wikipedia.org/wiki/Amdahlsches_Gesetz
Bei Spielen ist a) nicht gegeben.

Lade dir mal SharpDevelop mit dem .NET Framework 4.0 oder höher herunter und experimentiere mit den Parallel Tasks ("Parallel.for(...)"). Du wirst sehen, wie oft du bei praktischen Problemen auf Granit stößt. ;D
 
Kein Wunder, dass alle bei Windows 7 bleiben wollen. Microsoft hat es einfach verkackt, und zwar mit voller Absicht, um das gescheiterte Windows Phone in den Markt zu drücken (was nicht geklappt hat). Mit Windows 10 kommt dann noch "Datenkrake" als Gegenargument dazu, die beste Werbung für Windows 7.

zum Thema: Bei der Software dauert halt alles, aber nach und nach wird's besser: Die glibc nutzt jetzt AVX für Vektorberechnungen:

"Eine neue Bibliothek libmvec für mathematische Vektoroperationen wurde hinzugefügt. Sie enthält für die x86_64-Architektur optimierte Implementationen diverser mathematischer Funktionen, wenn diese auf einem Vektor (Array) von Eingabewerten ausgeführt werden sollen, und nutzt die Prozessorerweiterungen SSE oder AVX, die mittlerweile bis zu 16 einfach genaue oder 8 doppelt genaue Gleitkommazahlen parallel verarbeiten können."
http://www.pro-linux.de/news/1/22644/glibc-222-mit-neuer-vektorbibliothek-und-unicode-70.html
 
Danke für den Test! *great*

Dann wird mit der neuen glibc ja schon wieder ein emerge -eu world fällig..
 
@ONH
Dann frage ich mich aber wozu man dann überhaupt noch neue Rechner kaufen sollte wenn die Mehrleistung eh nicht benötigt wird.

@miriquidi
Und dennoch beweist vor allem der Spiele Bereich das diese ach so plausible Argumentation nichts anderes als eine Rechtfertigung für fehlende Weiterentwicklung und damit in meinen Augen Blödsinn ist denn wie von Zauberhand ist es später dann auf einmal doch möglich mehr Kerne zu nutzen. Und auch weiterhin sehe ich dafür keinen Grund aktuelle Befehlssätze zu ignorieren.

Was ich mich aber frage ist wozu die Audio Titel aus meinem Beispiel gleich gross sein sollen wenn sie ohnehin getrennt auf den Kernen abgearbeitet werden oder hast du nur den Fehler begangen mehr Instanzen laufen lassen zu wollen als Kerne vorhanden sind und damit an meinem Beispiel vorbei zu reden?
Das mit der CD ist übrigens das absolut schlechteste Beispiel da hier das CD Laufwerk bereits bei einem Kern der limitierende Faktor ist. Versucht man sich dann auch noch an parallelen Zugriffen bricht es aufgrund der hohen Zugriffszeiten nur noch stärker ein.

@derDruide
Ist aber letztendlich auch "nur" ein pro Linux Argument. ;)
 
Versuch erst einmal selbst etwas parallelisiertes auf die Beine zu stellen, dann bemerkst du die ganzen Stolpersteine. Ich bin keine Spieleprogrammierer, nur ist es recht offensichtlich, dass die Objekte in der virtuellen Welt miteinander wechselwirken.
Deinen Einwand mit dem Audio verstehe ich nicht. Meine Lösung wäre pro CPU-Kern einmal Lame oder Opus anzuwerfen und zu hoffen, dass man für jeden Kern genug Audio-Dateien hat. Den MP3/OGG/Opus/...-Algorithmus zu parallelisieren, ohne dabei Encodiertqualität einzubüßen, halte ich für schwierig.
 
Soll ich auch erst ein Ingenieuer- und Physikstudium durchziehen um zu wissen das ein Auto mit 4 Rädern sicherer auf der Straße liegt als eines mit 3?
Die bisherige Entwicklung hat in meinen Augen doch bereits das der Großteil nur eine Rechtfertigung für eine vernachlässigte technologische Weiterentwicklung ist.
Wie wäre es denn wenn einfach die komplette Weiterentwicklung eingestellt wird? Ist ja auch viel billiger und bequemer.
 
Interessant wie aus nem richtig guten Test-Artikel v. Nero so ein Thread wird.. :] *nein*
 
Wie wäre es denn wenn einfach die komplette Weiterentwicklung eingestellt wird? Ist ja auch viel billiger und bequemer.

*great*

Dazu noch AMD Abschaffen weil sie ja Immer was Neues auf den Mark bringen wollen........

Aber Den Herd will keiner mehr so anmachen.:]

 
Interessant wie aus nem richtig guten Test-Artikel v. Nero so ein Thread wird.. :] *nein*

Sorry aber so wie ich das sehe passt es doch ganz gut denn es zeigt wo das wirkliche Problem ist. Die Berücksichtigung der neuer Technologieen in der Software.
Der Artigel zeigt doch sehr gut welche potentielle Leistung in der Hardware steckt.
Wenn ich das richtig überschlagen habe dann gewinnt Lame mit der amdbd Optimierung gute 25% Leistung und das dürfte auf die aktuellen CPU Befehlssätze zurück zu führen sein. An der Stelle wäre mal interessant wie Intels Prozessoren ab dem Haswell davon profitieren würden.
Wenn also wieder jemand wegen mangelhafter Leistungssteigerungen jammert...genau gier wird der Löwenanteil versenkt weil die Hardware einfach ungenutzt brach liegt.

Kein Wunder das der x86er Markt rückläufig ist und warum der Bereich immer wieder tot gesagt wird, bei der Entwicklung der letzten Jahre kann ich das sogar verstehen.
Fehlende Weiterentwicklung ist doch das sicherste Anzeichen für einen sterbenden Markt, nur ist es ein langsamer Tot.

Und ich mecker hier als Kunde dem die lausige Software Qualität diverser Spiele, der puren Ignoranz in der Windows Welt, sowie der schön Rederei diverser Nutzer einfach nur noch sauer aufstößt und lese ich dann noch Rechtfertigungen der Marke "es wird halt in ST mit Programmiersprache *sowieso* programmiert weil MT schwieriger ist also finde dich damit ab", also nicht das es garkeine Mehrleistung bringen würde oder eine ander Programmiersprache es besser könnte, dann fallen mir dazu nur noch Worte ein die hier nicht hin gehören.

Aktuell warte ich angesichts der Windows Entwicklung ohnehin nur noch darauf das mehr Spiele Schmieden in die Linux Welt einsteigen und Windows damit für mich gestorben ist. Fallen die Ergebnisse dann entsprechend besser aus ist Windows für mich gestorben denn Briefe schreiben und im Netz Surfen kann ich dann auch unter Linux.


Sorry das es etwas ausladener wurde aber dafür bin ich mit dem Thema dann auch durch...
 
Aktuell warte ich angesichts der Windows Entwicklung ohnehin nur noch darauf das mehr Spiele Schmieden in die Linux Welt einsteigen und Windows damit für mich gestorben ist. Fallen die Ergebnisse dann entsprechend besser aus ist Windows für mich gestorben denn Briefe schreiben und im Netz Surfen kann ich dann auch unter Linux.
Crossplatform wird scheinbar angestrebt, das zeigt auch die API Vulkan.
Bin mal auf die ersten Linux / Win 10 Spiele gespannt mit der gepimten Mantle API. ;)

Bis dahin nutz ich einfach Mantle unter Windows 10: http://abload.de/img/bf4_windowmode_cfxmxs97.jpg
 
Von der Vulkan API erhoffe ich mir im Spiele bereich auch einen ernsthaften Konkurrenten für Direct3D.
Das letzte was ich davon laß war ja das sie parallel zu OpenGL laufen soll. Damit kann sich dann der ganze professionelle Bereich auf OpenGL beziehen wärend Vulkan den Spiele Bereich abdeken könnte, wodurch sich die Bereiche bei der Weiterentwicklung nicht gegenseitig behindern würden und neue Vunktionen deutlich schneller ihren Weg in die neue API finden könnten. Ich für meinen Teil nutze aber weiterhin Windows 7 und Mantle zum Spielen. Windows 10 ist für mich keine Alternative da ich dafür kein Geld ausgeben würde.
 
Sehr aufwändiger und schöner Test, leider ohne Belang, da der Vergleich mit Intel nicht vollzogen wurde.
Irgendwie kann ich gerade kein Brett finden, das gross genug ist. :]


@topic

Schöner Test! *great*
 
Von der Vulkan API erhoffe ich mir im Spiele bereich auch einen ernsthaften Konkurrenten für Direct3D.
Das letzte was ich davon laß war ja das sie parallel zu OpenGL laufen soll. Damit kann sich dann der ganze professionelle Bereich auf OpenGL beziehen wärend Vulkan den Spiele Bereich abdeken könnte, wodurch sich die Bereiche bei der Weiterentwicklung nicht gegenseitig behindern würden und neue Vunktionen deutlich schneller ihren Weg in die neue API finden könnten. Ich für meinen Teil nutze aber weiterhin Windows 7 und Mantle zum Spielen. Windows 10 ist für mich keine Alternative da ich dafür kein Geld ausgeben würde.
Scheinbar soll Frost Bite schon dran sein, die Engine von Mantle auf Vulkan zu portieren...
Der geringere Overhead kann z.B. genutzt werden um CPU Physik zu nutzen, dann sollte auch endlich mehr als 4 Threads @ min 50% laufen.

Da die Mathematik Bibliotheken schon auf AVX umschwenken, ist es zumindest die richtige Richtung. ;)
 
Die bisherige Entwicklung hat in meinen Augen doch bereits das der Großteil nur eine Rechtfertigung für eine vernachlässigte technologische Weiterentwicklung ist.
Wie wäre es denn wenn einfach die komplette Weiterentwicklung eingestellt wird? Ist ja auch viel billiger und bequemer.

Ich bin ja auch schon Jahre darüber hergezogen, dass die Softwaredengler der Hardware 5-10 Jahre hinterherhinken, inzwischen sind es wohl mehr als 10! Wäre interessant mal nachzuforschen wie flächendeckend sich SSE3 inzwischen durchgesetzt hat ;)
Es gibt da ein Zitat von Benjamin Franklin über seine Landsleute : "Wir sind so schlechte Farmer, weil wir so viel Land haben"
.... das ist schon jahrelang im Bereich der Rechner Phase : "Why worry , Hardware (spätestens die nächste Generation) wird´s schon richten!"
Nur funktioniert das nicht mehr so :-/ Takt hat einfach noch alles mitgerissen , IPC in weiten Teilen, jedoch Multicore ist da deutlich weniger komfortabel..... Gehässigerweise reicht es allzuoft nichtmal an ein paar Rädchen zu drehen und frisch zu kompilieren, man müsste an den (z.T. jahrelang gewachsenen) Code konzeptionell Hand anlegen :-[

Ganz bittere Ironie ist in diesem Zusammenhang natürlich, dass Wünsche, die vor 15Jahren an mangelnder Rechenleistung strandeten, inzwischen anscheinend völlig vergessen sind, wo Resourcen nicht mehr limitieren.... :-*
Zum Bleistift erstklassige KI in Computerspielen, damals ein Problem, weil die gerade wenn viel los , den Kern blockierten :o , heuer könnte man ihr in einem potenten Spielerechner einen kompletten Kern und die iGPU übereignen *oink* , will aber anscheinend keiner :P

Mmoe
 
Nun ja, die ersten Dual Cores kamen vor 10 Jahren raus aber bezieht man Dual CPU Systeme wie mit dem Abit BP6 oder einem ASUS A7M266-D mit ein ist das Ergebnis mehr als traurig. Die Quads kamen 2007. 8 Threads kamen spätestens mit Intels i7 ins Spiel.
Hätte wohl keiner ahnen können das die Prozessoren mehr Kerne bekommen...
 
Zuletzt bearbeitet:
Wenn das alles nur in der Faulheit der Programmierer begründet ist, kann sich unser Held doch mal den LAME Codec vornehmen und ihn parallelisieren. Den Source-Code gibt es hier:
http://lame.sourceforge.net/download.php
Da du maximale Geschwindigkeit anstrebst, wäre eine Assembler-Lösung toll. Die soll aber sowohl auf dem alten K8 als auch auf einem Broadwell oder Excavator laufen.

EDIT: Mir fällt gerade auf, dass LibreOffice bei hohen Bildschirmauflösungen bei der fließenden Eingabe von Text in ein großes Textdokument mit einigen Bildern im Anzeigebereich auch nicht ganz so flüssig reagiert und den getippten Text mit vielleicht 500 ms Latenz darstellt. Vielleicht kannst du da etwas schreiben, damit die Anzeigearbeit der Buchstaben und das Rendern der Seite auf mehreren Kernen verteilt berechnet wird. Zur Zeit haben die meisten Büroarbeitscomputer vier Threads, um etwas zukunftsfähig zu sein, sollte man diese wichtige Aufgabe schon auf acht logischer Kerne verteilen. :)
 
Zuletzt bearbeitet:
@Nero

Sehr schöner Test und Überblick *great*

Hoffen wir mal das AMD, jetzt wo dort wieder mehr Techniker als BWLer und Marketingtrommler das Sagen haben, Boden unter die Füße bekommt.
 
EDIT: Mir fällt gerade auf, dass LibreOffice bei hohen Bildschirmauflösungen bei der fließenden Eingabe von Text in ein großes Textdokument mit einigen Bildern im Anzeigebereich auch nicht ganz so flüssig reagiert und den getippten Text mit vielleicht 500 ms Latenz darstellt. Vielleicht kannst du da etwas schreiben, damit die Anzeigearbeit der Buchstaben und das Rendern der Seite auf mehreren Kernen verteilt berechnet wird. Zur Zeit haben die meisten Büroarbeitscomputer vier Threads, um etwas zukunftsfähig zu sein, sollte man diese wichtige Aufgabe schon auf acht logischer Kerne verteilen. :)

Ewentühl wäre das aber eine Aufgabenstellung für die GCN-ALUs , Du Spezialist ;)

___________________________________________

Mal kurz zurück zum Thema

Der Test zeigt wünnebar, was AMD aus dem eher verkorksten Bullidesign noch rausgezuzzelt hat ;D
Und auch wenn Excavator bzw. Carrizo definitiv der Effizienzprimus der Familie ist, hätte ich schon dreimal um den Block Rosenblätter gestreut , wenn sich ein Hersteller erbarmt hätte, ein vernünftiges Gerät mit Kaveri speziell dem A10-7300 (oder der"B"version) zu bauen :-/
... und man komme mir jetzt bitte nicht getreu dem Motto "Unter den Blinden ist der Einäugige König.." mit HP :-X

Mmoe
 
@ miriquidi
Die klassische maßlose Übertreibung um Einfallslosigkeit zu rechtfertigen?
Seit wann kann sowas wie ein Compiler neue Funktionen hinzufügen die in dem Ursprungscode nicht vorgesehen sind?
Was hat das von dir angedichtete Anstreben maximaler Geschwindigkeit mit der von mir umschriebenen Nutzung vorhandener Ressourcen durch simples Multitasking mit einer gemeinsamen Dateiliste zu tuen?
 
@ miriquidi
Die klassische maßlose Übertreibung um Einfallslosigkeit zu rechtfertigen?
Dann setzte erst einmal selbst ein Stückchen parallele Software um, bevor du der Software-Branche 'Einfallslosigkeit' vorwirfst. Ein Compiler parallelisiert dir den Code i.d.R. nicht, da musst du schon an den mathematischen Algorithmus dahinter ran. Und dann wirst du sehr schnell merken, dass dir 8 parallele MP3-Encodierungsprozesse nichts nützen, wenn du nur genau eine Datei umzurechnen hast. Algorithmen zu finden, die immer gut mit der Kernzahl skalieren, ist nunmal nicht in 3 Tagen erledigt.
 
Zurück
Oben Unten