News Tape-Out von AMDs „Bulldozer“ erfolgt

[jodd]

Habt ihr kein ICQ o.ä. um euch über so Zeug zu unterhalten? Das Interessiert sonst kein Mensch. Müssen wir noch ein mal eingreifen ist hier Schluss und es gibt Karten.

 

[silent-efficiency]

Mich interessiert noch weniger was AMDs Marketing alles für Zeug sich einfallen lässt um ihre "APU" zu promoten, für die es noch immer keine Anwendungen gibt, laut Wolfgang.

Vielleicht solltest du dann diese Beiträge, die AMDs Marketing zitieren auch ins Aquarium verschieben, Jodd. Wenn du Diskussion, die sich darum dreht, dahin verschiebst.

 

[gruffi]

Gibt mittlerweile schon eine ganze Reihe von Anwendungen. Selbst Browser bieten ja heutzutage GPU-Beschleunigung.

@jodd
Kannst du mal genauer erklären, was hier keinen Menschen interessiert? Solange es um das Thema geht, also Bulldozer, sehe ich keinen, den es nicht interessiert.

 

[silent-efficiency]

Gibt mittlerweile schon eine ganze Reihe von Anwendungen....

Erzähl das dem Wolfgang, der wird dir was anderes erzählen.
https://www.computerbase.de/forum/threads/computerbase-tests.749467/#post-8132826

 

[gruffi]

Ehrlich gesagt lese ich aus Wolfgangs Beitrag nicht heraus, dass es "noch immer keine Anwendungen gibt". Er wollte wohl vielmehr sagen, dass es nur langsam vorangeht. Und so falsch ist das ja auch nicht.

 

[y33H@]

Also auf dem Papier sieht Bulldozer eindeutig besser aus.

Das sah die Radeon HD2900 XT gegenüber der Geforce 8800 GTX auch *SCNR*

Bulldozer ist was komplett Neues und es stecken viele gute Ideen drin. Dennoch ist Intel pro Takt aktuell schon 20-30% in Front und Sandy wird das noch steigern - und an Sandy muss sich der Bulldozer messen. Hoffen wir, dass er das kann und nicht wie seit dem Phenom I AMD nur durch den Preis konkurriert und das Topmodell [1090T] gerade mal Intels obere Mittelklasse erreicht [i7-870]. Das wäre sehr schade und nicht im Sinne des Wettbewerbs oder der Käufer.

 

[gruffi]

Das sah die Radeon HD2900 XT gegenüber der Geforce 8800 GTX auch *SCNR*

Und was daraus geworden ist, wissen wir ja. ATI ist nVidia mittlerweile technologisch deutlich voraus, auch wenn es 2 Generationen gedauert hat, um die Kinderkrankheiten auszumerzen und an der Performance-Schraube zu drehen. Hier hat sich das Papier letztendlich doch durchgesetzt.
Ich sehe da aber keinen wirklichen Zusammenhang. Bulldozer ist eine ganz andere Geschichte als die Herausforderungen, die R600 und G80 seinerzeit mit der Unified Shader Architecture hatten.

Bulldozer ist was komplett Neues und es stecken viele gute Ideen drin. Dennoch ist Intel pro Takt aktuell schon 20-30% in Front und Sandy wird das noch steigern

Rein hardwareseitig ist Intel pro Takt lediglich 10% vorne, bezogen auf einen Thread. Mit softwareseitigen Nachteilen für AMD wie unter Windows oft vorhanden, kannst du von mir aus noch bis zu 5% hinzurechnen. Das sollte Bulldozer locker wettmachen können. Selbst wenn Sandy Bridge nochmal ~10% drauflegen sollte, ist das machbar. Was die gesamten Rechenkapazitäten der CPU betrifft, da hat der 6-Kerner von AMD schon mit Nehalem pro Takt gleichgezogen, mindestens. Ausserdem geht es weniger um Pro-Takt, sondern vielmehr um Pro-Thread und Skalierung bei gleicher Leistungsaufnahme. Nur das zählt für uns im Endeffekt.

Hoffen wir, dass er das kann und nicht wie seit dem Phenom I AMD nur durch den Preis konkurriert und das Topmodell [1090T] gerade mal Intels obere Mittelklasse erreicht [i7-870]. Das wäre sehr schade und nicht im Sinne des Wettbewerbs oder der Käufer.

Was heisst denn "gerade mal"? Man sollte sich immer bewusst sein, dass AMD gar kein Interesse daran hat, im Client Markt die schnellsten CPUs anzubieten, selbst wenn sie es theoretisch könnten. Die schnellsten CPUs gibt es momentan nur für Server und das wird auch mit Bulldozer so sein. Wenn du zu dem 0,0000001% Klientel gehörst, die immer das absolut schnellste für Desktop wollen, dann musst du wohl bei Intel bleiben. Alle anderen bekommen bei AMD mehr als ausreichend Alternativen.

 

[Schaffe89]

Rein hardwareseitig ist Intel pro Takt lediglich 10% vorne, bezogen auf einen Thread. Mit softwareseitigen Nachteilen für AMD wie unter Windows oft vorhanden, kannst du von mir aus noch bis zu 5% hinzurechnen.

Was bedeutet denn Hardwareseitig und wie kann man das messen? Es ist auch recht einfach es immer auf die Compiler zu schieben. Abgesehen davon, muss man nur mal die Logik betrachten und da hat Intel deutlich mehr im gegensatz zu AMD.
Soviel wie ich in den Benches sehe sind es gut 20%.

 

[y33H@]

@ gruffi

Ja, von R600 bis zum in Front liegenden Cypress hat's ja auch nur mal gepflegt ein paar Jahre gedauert. Zwei Gens? RV670 war immer noch langsamer, RV770 auch. Erst Cypress überflügelte GT200, bei schlechterem AF allerdings (nach wie vor). Und HW-seitig ist schön und gut [Beleg?], aber wie wie heißt es doch gleich: Was hinten raus kommt, zählt. Und da sind es eben 20-30% pro Takt und Thread - mal mehr, mal weniger.

Man sollte sich immer bewusst sein, dass AMD gar kein Interesse daran hat, im Client Markt die schnellsten CPUs anzubieten, selbst wenn sie es theoretisch könnten.

So kann man es natürlich auf darstellen. Gibt's zu dieser These auch eine Quelle seitens AMD?

 

[gruffi]

@Schaffe89

Hardwareseitig heisst, was die Hardware theoretisch hergibt. Messen kannst du das am besten, wenn du Compiler verwendest, die für die jeweilige Hardware ausreichend optimieren. Und da sind es eben nur etwa 10% Unterschied. Die unter Windows meist verwendeten MSC und ICC arbeiten für AMD CPUs schlichtweg unzureichend.


@y33H@

Technologisch voraus zu sein, hat nichts mit langsamer oder schneller zu tun. Da zählen ganz andere Faktoren wie Performance pro Watt und Performance pro mm². Und da war ATI schon mit dem RV770 voraus. Mit dem RV870 deutlich, da auch der zeitliche Aspekt noch hinzu kam.

Und nein, pro Takt und Thread sind es selbst unter Windows maximal ~15% zwischen K10.5 und Nehalem, falls überhaupt. Wie viele scheinst auch du zu vergessen, dass etliche Scores bei Intel durch den Turbo verzerrt werden. Ansonsten, zeige mir mal bitte deine Quelle, wo du diese angeblichen 20-30% herhast. Dann kann ich dir besser erklären, was du da falsch interpretierst.

Und ja, Quellen gibt es. Lies dir zB die Aussagen von JF durch.

 

[silent-efficiency]

Warum macht AMD nicht einfach ein Design, dass mit den besagten Compilern super zurecht kommt? Warum wollen die sich was eigenes Backen, wenn es defakto keine Alternative zu diesen Compilern auf dem Markt gibt, bzw. gerade diese Compiler am meisten verwendet werden?! Es ist doch Blödsinn eine CPU zu entwerfen, die mit einem theoretischen Compiler, denn niemand einsetzt, die beste Leistung bringt^^

 

[Sunnyvale]

Weil die Intel Compiler AMD grundsätzlich von den höheren Optimierungen ausschließen.
Also hieße das Intel CPU 1:1 nachbauen und CPUID fälschen.

Aus dem Stadium ist AMD (Gott sei dank) seit >15 Jahren raus.

Beim MSC liegt die Sache noch etwas anders, der ist von vornherein nicht der schnellste.
Weiß allerdings nicht, ob die in letzter Zeit aufgeholt haben.

 

[silent-efficiency]

Weil die Intel Compiler AMD grundsätzlich von den höheren Optimierungen ausschließen.

Wäre so etwas nicht ein Fall für ein Gericht? Ein Produkt, dass ein anderes Produkt grundsätzlich von etwas ausschließt, worauf ein anderes Produkt zugreifen kann, nur wegen einer anderen ID, ist doch unlauterer Wettbewerb oder so was in der Art. Auf jeden Fall ist das Verboten, insbesondere bei einem Monopolisten wie Intel, wäre das doch höhst Wettbewerbsverzerrend und ein Fall fürs Gericht. Wenn also deine Behauptung stimmt, warum hat AMD dann diese nicht auch beim Gericht einklagen wollen? Warum haben die sich auf die Rabataktionen und andere Verkaufsmethodigen von Intel beschränkt?

 

[gruffi]

Warum macht AMD nicht einfach ein Design, dass mit den besagten Compilern super zurecht kommt?

Dann müssten sie Intels Design kopieren. Und dafür haben sie schon lange keine Lizenz mehr. Ausserdem ist das sicherlich nicht der Anspruch von AMD.

Warum wollen die sich was eigenes Backen, wenn es defakto keine Alternative zu diesen Compilern auf dem Markt gibt, bzw. gerade diese Compiler am meisten verwendet werden?!

Natürlich gibt es Alternativen. In der Serverwelt werden ganz andere Compiler häufig für AMD verwendet, wie GCC oder PGI. Und diese können ja sehr gut für AMDs Hardware optimieren. Ausserdem ist nicht gesagt, dass zB MSC immer so bleiben wird. Vor geraumer Zeit gab es zB mal Stellenausschreibungen von AMD bezüglich MSC Integration. Man ist also schon daran interessiert, mit Microsoft besser zusammenzuarbeiten. Nur geht das nicht von heute auf morgen. Das ist ein Entwicklungsprozess, der Jahre dauert. Beim ICC auf der anderen Seite darf man sicherlich nicht erwarten, dass der für andere CPUs ausser Intel jemals ordentlich optimiert.

 

[silent-efficiency]

Dann müssten sie Intels Design kopieren.

Die Behauptung ist schlichtweg falsch und jeder weiß das, der sich mit der Hardware einer CPU auskennt. Der Compiler liefert den Code und diesen Code muss die CPU verarbeiten und kann dies auf verschiedene Art und Weise und Intels weg den Code zu verarbeiten ist nicht der einzigste um mit diesem besagten aus dem Compiler Kommenden Code die gleiche Performance herauszuholen.

Man ist also schon daran interessiert, mit Microsoft besser zusammenzuarbeiten. Nur geht das nicht von heute auf morgen.

Wenn du eine Wette um dein gesamtes Hab und Gut abgeben würdest. Auf welches Jahr in der Zukunft würdest du wetten, das AMD und MS hier die Früchte pflücken kann, so dass MS-Compiler endlich schneller als der von Intel ist und dann auch noch von vielen benutzt wird.

 

[gruffi]

Die Behauptung ist natürlich nicht falsch. Und jeder mit ein bisschen Ahnung vom Thema weiss das. Zumal es keine Behauptung ist, sondern schlichtweg ein Fakt.
Compiler liefern nicht DEN Code. Compiler optimieren ganz spezifisch auf die jeweilige Architektur, je nachdem, was ihnen als Schalter mitgegeben wird. Dabei werden Ausführungseinheiten, Cache, Mikrocode Anordnung, Befehlssatzerweiterungen, etc berücksichtigt. Und wenn AMD die gleichen Voraussetzungen bezüglich Compiler haben wollte, dann müssten sie auch hardwareseitig die gleichen Voraussetzungen schaffen, also Intels Design kopieren.


edit:

Wenn du eine Wette um dein gesamtes Hab und Gut abgeben würdest. Auf welches Jahr in der Zukunft würdest du wetten, das AMD und MS hier die Früchte pflücken kann, so dass MS-Compiler endlich schneller als der von Intel ist und dann auch noch von vielen benutzt wird.

Dass Microsofts Compiler schneller als der von Intel wird, darauf würde ich nicht wetten. Und unter Windows wird der MSC schon lange am häufigsten benutzt, was natürlich mit Microsofts umfangreicher Entwicklungsumgebung zusammenhängt.

 

[Complication]

@silent-efficiency
lol.. du musst auch lesen was jemand schreibt: Der einzige Weg den CPUID Check zu umgehen wäre ein exakter Nachbau.

 

[Sunnyvale]

Der Compiler liefert den Code

Und im Falle des Intel Compilers auf Intel CPUs wenn möglich hochoptimierte SSE - Befehle (die gleichzeitig andere Ausführungseinheiten frei halten) während das AMD System uralte x86_generic Befehle abarbeiten darf.

Reicht doch schon, ab und zu mal ein geschicktes Prefetch einzutreuen - dann rechnet der Intel schon, während AMD noch auf den Hauptspeicher wartet...

 

[silent-efficiency]

complication, du musst auch lesen, was jemand schreibt. Du sollst erst mal beweisen, dass AMD durch die CPUID benachteiligt wird. Und wenn du das kannst, kannst du vor Gericht ziehen und es nicht mir erzählen. Das gleiche gilt auch für dich Sunnyvale.

@gruffi
Kompiliert wird vor dem Ausführen der Anwendung, daher liefern sie auch nur den Code. Der Code ist fertig und kann durch verschiedene CPUs unverändert gejagt werden. Vor dem kompilieren kann man in der Tat auf eine bestimmte CPU hin optimieren, allerdings beschränkt sich diese "optimierung" auf Cachegrößen und andere äußere Parameter. Wie die CPU intern dann alles weitere rechnet kann völlig unterschiedlich sein.

 

[gruffi]

Der einzige Weg den CPUID Check zu umgehen wäre ein exakter Nachbau.

Wobei man dazu sagen muss, selbst den CPUID Check zu umgehen, hilft nur bedingt. Damit kann man zB nicht genutzte, obwohl unterstützte, Befehlssatzerweiterungen freischalten. Die ursprüngliche Heuristik, mit der der Mikrocode einst für die entsprechende Architektur erzeugt wurde, lässt sich damit natürlich nicht mehr ändern.

Kompiliert wird vor dem Ausführen der Anwendung

Nein. Kompiliert wird, wenn der Entwickler eine Executable erzeugen will. Wenn ein User diese ausführt, ist eine ganz andere Geschichte.

Der Code ist fertig und kann durch verschiedene CPUs unverändert gejagt werden.

Ja, solange wir von Maschinencode sprechen und die CPUs die jeweilige Befehlssatzarchitektur unterstützen. Deshalb ist der Code trotzdem auf eine bestimmte Mikroarchitektur zugeschnitten. Und wenn andere Schalter beim Kompilieren verwendet werden, entsteht eben auch anderer Maschinencode.

Vor dem kompilieren kann man in der Tat auf eine bestimmte CPU hin optimieren, allerdings beschränkt sich diese "optimierung" auf Cachegrößen und andere äußere Parameter. Wie die CPU intern dann alles weitere rechnet kann völlig unterschiedlich sein.

Äussere Parameter? Diese Optimierung berücksichtigt die Spezifika der jeweiligen Mikroarchitektur. Du scheinst zu glauben, das wäre nicht weiter wichtig. Das genaue Gegenteil ist der Fall, gerade das ist ausschlaggebend.