News AMD: Acht „Bulldozer“ und elf „Llano“ ab Juni?

[Raucherdackel]

Nehmen wir doch mal MainConcept H.264/AVC Pro als Referenz.

Der Mainconcept Decoder nutzt Intels SSE4 Befehlssatz, aber den SSE4a von AMD nicht.

Ich will mich in die Leistungsdiskussion nicht einmischen, weil bei jeder anderen Software ein anderes Leistungsverhältnis zwischen AMD und Intel rauskommt. Ich habe früher öfters Videomaterial mit Nero Recode umgewandelt, und da war mein alter S939 Opteron mit seinen 2,8GHz erheblich schneller als der E6600 @3,2GHz meines Bruders - Festplatte als mögliche Bremse ausgeschlossen, er hatte RAID, ich nicht.

Ich finde, am besten kann man CPUs mit hochspezialisierter Software testen, weshalb ich, wenns um pure Leistung geht, Serverbenchmarks bevorzuge. Das Serverbenchmarks allerdings wenig mit den alltäglichen Aufgaben, die mein Prozessor täglich abwickeln muss, gemeinsam haben, ist die Kehrseite der Medaille.

 

[freifacht]

Hier ein wenig was zur Ernüchterung.

http://www.heise.de/newsticker/meldung/US-Wettbewerbshueter-einigen-sich-mit-Intel-1050693.html

So wird bei Intel gearbeitet,man beachte vor allem die Intel-Compiler- Schummelei

Auszug heise

Intel muss ferner insgesamt bis zu 10 Millionen US-Dollar an Firmen auszahlen, die ihre mit Intel-Compilern hergestellte Software neu übersetzen müssen, damit sie auch auf Nicht-Intel-Prozessoren so schnell wie möglich läuft. Strafzahlungen muss Intel allerdings nicht leisten. Intel akzeptiert die FTC-Vorgaben, erkennt aber kein Fehlverhalten an – eine solche Sprachregelung gab es auch bei der Einigung mit AMD (AMD Settlement).

Irgendwie habe ich ein Verständnisproblem:
Intel versorgt Softwarefirmen mit Compilern, damit deren Software auf Intel-Hardware läuft.
Jetzt muss Intel Strafe dafür zahlen, dass die mit Intel-Compilern übersetzte Software auf anderen Plattformen nicht optimal läuft.
Sehe ich das soweit richtig?
Warum soll aber Intel Compiler für bspw. AMD herstellen?
Warum versorgt AMD nicht selber die Softwarehersteller mit eigenen Compilern? Das ist doch nicht Intels Aufgabe...

 

[CHAOSMAYHEMSOAP]

Es geht darum, daß der Intel Compiler CPUs, die nicht von Intel stammen, benachteiligt.

Gaukelt man z.B. einem VIA Nano vor, er wäre von Intel, so erhöht sich die Speicherperformance um sagenhafte 47%.

Siehe auch:

http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1282229350
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1217539570
http://www.agner.org/optimize/blog/read.php?i=49
http://en.wikipedia.org/wiki/Intel_C++_Compiler#Criticism

 

[freifacht]

DAS habe ich verstanden.
Aber warum soll es das Problem von Intel sein, dass andere Chip- und Prozessorhersteller die Softwarefirmen anscheinend nicht mit eigenen Compilern versorgen?

 

[kisser]

Es geht darum, daß der Intel Compiler CPUs, die nicht von Intel stammen, benachteiligt.

Was offenbar völliger Unsinn ist, wie die c't mal herausgefunden hat. Der vom Intel Compiler erzeugte Code ist mit Abstand der schnellste auf AMD CPUs vergleichen mit dem Microsoft oder GNU Compiler.

 

[deadohiosky]

Was offenbar völliger Unsinn ist, wie die c't mal herausgefunden hat. Der vom Intel Compiler erzeugte Code ist mit Abstand der schnellste auf AMD CPUs vergleichen mit dem Microsoft oder GNU Compiler.

Quelle/Link/ct' Artikel mit Ausgabennummer/Seitenzahl bitte. Habe "Schnellzugriff" (im Regal, 2 Meter von mir entfernt) auf jede ct' Ausgabe seit Anfang 2003. Ich hoffe deine Behauptung basiert nicht auf irgendwelchen Tests von vor 5,6,7 Jahren als der AMD lustigerweise besser mit dem Intel-Compiler zurechtkam als Intels eigene CPUs.

edit: Ich zitiere hier mal aus einem Blog der die Angelegenheit mit den Intel-Compilern der Öffentlichkeit erklärt:

http://www.agner.org/optimize/blog/read.php?i=49

Intel C++ compiler

The Intel C++ compiler has various options that allow the programmer to generate code for a specific instruction set or to make multiple versions of the code for different instruction sets with automatic CPU dispatching. Non-Intel processors will always get the generic version of the code if CPU dispatching is used. The default level for the generic code is SSE2 for version 11 and 12 of the compiler, and 386 for version 10 and earlier in 32-bit mode as indicated in the following table.

It may sound like a fair solution that each CPU vendor makes its own function libraries, but this can soon be a nightmare for the producers of application software. This goes against the very principle of having a standardized instruction set. And apparently, only Intel can afford the costs of optimizing large function libraries on the detailed instruction level. They don't make much money on these function libraries, and it is surely very costly to develop, test and optimize such a big library of complicated mathematical functions, let alone the costs of making a different version for every new instruction set extension. The AMD libraries cannot match this level of optimization, and VIA can hardly afford to make any function libraries at all.

Intel are putting themselves into an advantageous position by making better function libraries than everybody else, and they are taking advantage of this position by lowering the performance of common mathematical software on the CPUs of their competitors relative to their own. We have probably not seen the end of the legal battles yet.

Workarounds

At present, we don't know if or when Intel will make a new compiler and new software libraries that do not check the vendor ID string. In the meantime, here is what we can do about the problem.

* Use another compiler. In my tests, the Gnu compiler for Linux has an optimizing performance similar to the Intel compiler, but the Gnu function library (glibc) is inferior. All other compilers gave lower performance in my tests. There is no other Windows compiler with a similar performance, not even the Gnu compiler for Windows.

* Use the Intel software and patch the CPU dispatcher. In my C++ manual, I have provided the code for alternative CPU dispatchers for Intel's compiler and function libraries and descriptions on how to patch them into your software. This, of course, relies on undocumented details of the Intel software. This dispatcher-patch can improve performance on non-Intel processors considerably in many cases.

* Never trust any benchmark unless it is open source and compiled with a neutral compiler, such as Gnu or Microsoft.

* It is possible to change the CPUID of AMD processors by using the AMD virtualization instructions. I hope that somebody will volunteer to make a program for this purpose. This will make it easy for anybody to check if their benchmark is fair and to improve the performance of software compiled with the Intel compiler on AMD processors.

 

[MacroWelle]

DAS habe ich verstanden.
Aber warum soll es das Problem von Intel sein, dass andere Chip- und Prozessorhersteller die Softwarefirmen anscheinend nicht mit eigenen Compilern versorgen?

Das ist die alte Leier, die wir hier schon x-Tausendmal durchgekaut haben:
Intel hat eine Monopolstellung.

Deswegen steht Intel unter Beobachtung. Genauso wie jeder andere Monopolist auch, egal ob er Beton herstellt oder Mikrochips.

AMD baut auch Compiler: PGI, GCC, Open64, Zusammenarbeit mit Microsoft. Aber da sind wir beim Monopol: Intel hat einen Compiler, der sowohl insgesamt gut also auch relativ gut auf Intel optimiert. Intel hat einen Marktanteil von 80%, die meisten Rechner laufen also mit Intel. Was meinst du, welchen Compiler die Leute verwenden. Genau.

Normalerweise wäre das kein Problem, das Problem entsteht erst durch das Monopol. Henne-Ei-Problem. Die Konkurrenz funktioniert strukturell nicht, also funktioniert der Markt nicht gut für die Kunden, also muss man eingreifen.

/EDIT
Wenn ich mich richtig erinnere (bin mir nicht sicher) war es sogar so, dass der Intel-Compiler nicht die technischen Features der CPUs abfragt um Optimierungen zu schalten, sondern den Hersteller. Und das ohne technischen Grund.

Zum Thema Leistung: wenn man richtige Werte haben will, brauchts Open-Source-Benchmarks und -compiler oder zumindest irgendwie neutrale/transparente Komponenten. Wie man ja hier lesen kann, ist alles andere begrenzt aussagekräftig.

@CHAOSMAYHEMSOAP
Danke für den Link, den wollte ich schon lange mal speichern

 

[ice-breaker]

DAS habe ich verstanden.
Aber warum soll es das Problem von Intel sein, dass andere Chip- und Prozessorhersteller die Softwarefirmen anscheinend nicht mit eigenen Compilern versorgen?

Die Intel Compiler kosten ein Vermögen, "versorgt" wird da niemand mit, da ist es auch für die Käufer ein Unding, dass auf AMD-Systemen die Leistung deutlich schlechter ist.

Man sollte dem Intel-Compiler-Verhalten aber bei solchen Benchmarks nicht zuviel Relevanz zusprechen, der Compiler ist so teuer, dass kaum jemand ihn für die Programme des Testfeldes nutzen wird, vor allem weil der OpenSource-Compiler gcc auch wirklich gute Resultate abliefert, aber natürlich nicht mit dem Intel Compiler vergleichbar ist.

Ich finde, am besten kann man CPUs mit hochspezialisierter Software testen, weshalb ich, wenns um pure Leistung geht, Serverbenchmarks bevorzuge.

sehe ich genauso, sollte ComputerBase mal einführen.
z.B. mehr Wert auf SPECjvm2008 legen, denn die JVM interessiert sich nicht wirklich ob es ein Intel oder AMD Prozessor ist und kann mehr Kerne auslasten, als ein Desktop-Prozessor heute hat.

 

[Krautmaster]

wir nehmen also realitätsferne Benchmarks um damit einen möglichst realistischen Leistungswert zu erhalten?

Is doch für mich als Kunde ob Werte mit SSE3, 4 4a oder diversen optimierten Compiler bessere Performance bieten...

Natürlich war der genannte 144% Wert der in meinem wahllos herausgegriffenen Benchmark erreicht wurde ein recht hoher. Im Normalfall sollten nicht immer diese 44% Vorsprung bei selbem Takt erreicht werden, das ist klar. Aber selbst 30% wären ohne große, weitreichende Architekturänderungen, wie sie Bulldozer mit sich bringt, nicht machbar. Ich denke die Kerne von Llano werden leicht über Phenom II Niveau liegen.

 

[held2000]

Llano wird mehr durch die GPU Leistung glänzen die CPU Leistung da stimme ich zu ca PhenomII Niveau...

Llano ist glaube ich zuminndest von AMD stark auf den Mobilen Bereich zugeschnitten, die Desktopversionen sind übertrieben gesehen nur ein Nebenprodukt..natürlich auch gewollt aber im Fokus ist der "vernachlässigte" Mobil Bereich.

Llano ist vlt nur ein Lückenfüller bis Bulldozer Mobil kommt..trotzdem sollte man Ihn nicht unterschätzen.

Bulldozer die grosse "Unbekannt" das Spitzenmodel 4 Module hoher Takt wird schon gut Power haben...bin wirklich gespannt auf die ersten richtigen Test_s

Die meisten Interessieren sich ja wohl für Bulldozer..ich für Llano "siehe Signatur" der dürfte meine Bedürfnisse gut abdecken. ...wäre dann mein 1ster 4 Kern Prozessor MFG

 

[Crystal]

Das neue Boxedverpackungsdesign.

Auf PCGH habe ich über den Bulldozer folgendes gelesen:

Die ISSCC 2011 verriet AMD zudem, dass ein Modul 213 Millionen Transistoren auf 30,1 mm² fasst, das Design ist für 0,8 bis 1,3 Volt ausgelegt. AMD spricht davon, dass ein 8-kerniger Bulldozer weniger Die-Fläche verbraucht als ein Thuban (346 mm²), Hans de Vries von Chip-Architekt schätzt derzeit (Ende Februar 2010) 292 mm². Das Bulldozer-Design soll 3,5 GHz und mehr erreichen, inklusive Turbocore - allerdings ist es von Haus hochtaktend ausgelegt, die Frequenzen lassen sich also nicht direkt mit einem Phenom II vergleichen. Auch sagt der hohe Takt nicht zwingend etwas über den Stromverbrauch des Designs aus. Der Cache bzw. die CPU-Northbridge des Bulldozer läuft mit 1,1 Volt und erreicht 2,4 GHz und unterstützt bis zu DDR3-1866 - ein Phenom II kommt auf nur 2,0 GHz und DDR3-1333. All diese Informationen sprechen zusammen mit der neuen, teils sehr mächtigen FPU für eine massiv gesteigerte Pro-Takt-Leistung gegenüber dem Phenom II. Der Bulldozer mit seinem innovativen Modul-Aufbau wird für das zweite Quartal 2011 erwartet und setzt den neuen Sockel AM3+ zwingend voraus.

• 8 Kerne und kleiner als aktueller 6 Kerniger Thuban
• Hoher Basistakt und 3,5Ghz mit TC2
• Die NB läuft +400Mhz mehr und DDR3 1866
• Mächtige FPU und massiv gesteigerte Pro Takt leistung

Also mit mehr Takt, "viel mehr" Performance pro Takt, jeweils verteilt auf 8 Kerne und das alles bei 95/125 TDP und kleiner Die Fläche. Klingt alles bombastisch

Aber irgendwie wiederspricht sich dies mit den früher gesagtem, dass ein BD Kern nur 80/90% Leistung eines gängigen Kernes erreichen soll oder? Ist die Frage die ich mir stelle. Kann man anhand dieser Infos irgendwie die Performance des BD einigermaßen einschätzen?

 

[Athlonscout]

Aber irgendwie wiederspricht sich dies mit den früher gesagtem, dass ein BD Kern nur 80/90% Leistung eines gängigen Kernes erreichen soll oder?

Oh Mann, wie oft denn noch!

Mit den Prozentangaben wird der Vergleich eines Bulldozer Moduls zu einem hypothetischen konventionellem Mehr(2)kernprozessor auf BD Basis gezogen.

 

[Felixxz21]

BD sollte nicht 80% der Leistung gängiger DualCores erreichen sondern ein Modul sollte 80% der Leistung eines fiktiven BD DualCores haben, bei dem auch wirklich alles zweimal vorhanden ist, sprich klassische, nichtmodul Bauweise.

Von der Leistung her schätze ich den 8 Core BD zwischen 6 und 8 Kern SandyBridge ein.

 

[deadohiosky]

Ihr vergesst beide einen entscheiden Faktor: Die Aussage ist 90% eines fiktiven Kerns, bzw 180% eines Moduls gegenüber 200% eines Zweikerners, jedoch verbraucht der 2te Kern nur 12% mehr Die-Fläche, das ist die entscheidende und wichtige Information. Das heißt dann auch mehr Performance pro Watt.

Ergänzung (14. März 2011)

Alle die denken, Bulldozer wird in unvorstellbare Preissphären aufsteigen, sollten sich mal diese Tabelle anschauen.

http://www.xbitlabs.com/news/cpu/di...ight_Core_i7_Sandy_Bridge_with_Bulldozer.html


Da werden dann wohl die 300/350 Euro wenn überhaupt nur durch die Topmodelle (zukünftige Black-Editions?) gerissen.


edit: wo wir (ich) gerade von Black Editions sprechen:

http://www.xbitlabs.com/news/cpu/di...ulldozer_Chips_Incoming_Details_Revealed.html