AMD Kabini APU / Jaguar CPU + Graphics Core Next GPU, 2-4 Kerne, 28nm TSMC, 2013

[gruffi]

Die blaue Konkurrenz hat es über die letzten Jahr hinbekommen, pro Takt immer mehr Befehle zu bearbeiten

Ja toll, in den letzten Jahren von Generation zu Generation 5-10% oder so. Wahnsinnsleistung. Das merkst du überhaupt nicht im Alltag. Das hat AMD übrigens auch geschafft. Mein Llano ist pro Takt auch gute 5% schneller als sein Vorgänger. Sry, aber wer immer noch glaubt, singlethreaded hätte so viel Bedeutung, lebt in der Steinzeit. Ich habe meinen Llano nicht gekauft, weil ich die gut 5% pro Takt gebraucht hätte. Das war auch bei meinem Regor zuvor kein Flaschenhals. Relativ aktuelle Desktop Prozessoren langweiligen sich eh die meiste Zeit. Ich habe einfach mehr Kerne für bessere Skalierung beim Multitasking gebraucht. Deshalb kam ein i3 auch nicht in Frage. HTT ist schlichtweg Müll. Daran ändert auch die höhere IPC bei einem Thread nix. Und ein i5 war mehr als doppelt so teuer. Nichts was die Mehrleistung ansatzweise rechtfertigen würde.

Intels Architektur-Optimierungen funktionieren fast immer

Nicht wirklich. Ich erinnere nur mal an Macro Op Fusion. Das hat lange Zeit überhaupt nicht unter 64-bit funktioniert und stand nur unter 32-bit zur Verfügung. Erst mit Nehalem wurde dies verbessert. Wobei ich mir nicht mal sicher bin, ob es heutzutage vollständig unter 64-bit funktioniert oder ob es immer noch Einschränkungen gibt. Genau wegen solcher Sachen hat Intel von 32- auf 64-bit oft weniger zulegen können als AMD. Wie auch immer, auch Intels Architekturoptimierungen funktionieren selten einfach so. Auch sie brauchen softwareseitigen Support. Leider ist dieser unter Windows aufgrund von MSC, ICC & Co viel umfangreicher als bei AMD. GCC hat zwar relativ guten AMD Support, wird unter Windows (MinGW) aber leider kaum genutzt. Vielleicht ändert sich das ja mal. Wäre zumindest wünschenswert. AMDs Compiler (Open64) gibt's leider nur für Linux. Vielleicht sollten sie da mal was Richtung Windows bereitstellen. Das wäre wesentlich hilfreicher als irgendwelche Optimierungen für den obsoleten x87 Befehlssatz.

AMD setzt darauf immer mehr Threads parallel zu bearbeiten

Ein klares jein. Die Parallelisierung der CPU wird aufgrund von HSA limitiert bleiben. Parallele Workloads werden in Zukunft die Aufgabe der GPU sein. Darüber hinaus erhöht AMD natürlich weiterhin die Performance pro Takt. Das haben sie schon immer gemacht und werden sie auch in Zukunft machen. Siehe Jaguar zuletzt, der 20% und mehr im Vergleich zu Bobcat zulegen konnte. Nur weil das bei Bulldozer ausnahmsweise mal anders war, ändert sich daran doch nix. Bulldozer sehe ich eher als Ausrutscher, der so nicht geplant war. Aber das Risiko hast du halt, wenn du eine Architektur von Grund auf neu entwickelst. Kurzfristig siehst du womöglich nicht die Leistungsgewinne, die man erwarten würde. Mittelfristig erwarte ich aber deutliche Vorteile im Vergleich zur alten Architektur. Bereits Piledriver hat schon um einiges zugelegt. Mehr ist dann sicherlich von Steamroller und Excavator zu erwarten. Intels Verbesserungen in diesem Bereich waren dagegen zuletzt auch nicht mehr Magerkost.

Das ist ein ziemlich blödes Argument, weil CB R10 oder andere alte Software auf einem modernen Intel trotz des alten Codes schneller durchläuft.

Einzig ein überspecter 8 Thread Prozessor mit 220 W TDP ist ein blödes Argument. Sowas brauche ich definitiv nicht, um einen alten 32-bit singlethreaded Benchmark laufen zu lassen. Wer sich einen 8-Thread Prozessor kauft, hat auch mehr Threads am laufen. Dass Haswell schneller ist, hat herzlich wenig mit irgendwelchen Verbesserungen der Architektur zu tun. Ein Core 2 war vor 6 Jahren in dem Benchmark auch schon etwa 30% schneller als ein K8 bei gleichem Takt. Wie gesagt, Cinebench ist seit jeher stark auf Intel optimiert. Das sagt uns herzlich wenig.

Ich wollte mit meinen Beiträgen auf der letzten Seite nur deutlich machen, dass es für AMD nicht darum gehen kann, ständig mehr Kerne und größere Vektoren zu verarbeiten.

Machen sie ja auch nicht. ZB für SSE5 war weiterhin 128-bit vorgesehen. Oder schau dir die aktuellen APUs an. Mehr als 4 Threads gibt's da im Moment nicht. Obwohl man sicherlich auch 6 oder gar 8 bieten könnte. Notfalls müsste man dann eben die iGPU etwas abspecken. Mit Thuban gab es zwar mehr Kerne. Der ist aber eigentlich ein Serverdesign und wurde aus der Not heraus geboren, um Intels reaktiviertem HTT auch im Client Markt etwas entgegenzusetzen. Ursprünglich war der gar nicht geplant. Das Gefühl von mehr Kernen und grösseren Vektoren habe ich momentan eher bei Intel (AVX, Nehalem/SB/IB-E, etc). Wobei beides in einem gewissen Rahmen absolut sinnvoll und positiv zu bewerten ist. Bei AMD geht es hingegen momentan vor allem um HSA, also eine vereinheitlichte Infrastruktur für CPU und GPU. Damit lässt sich mehr gewinnen als mit ILP. ILP ist limitiert. Du kannst nicht unendlich viele Instruktionen eines Threads parallel verarbeiten. Ausserdem sollte man Programmierer auch nicht zum Stillstand verleiten. Parallelisierung kann nun mal wesentlich effizienter sein. Daher sollte man Architekturen auch dahingehend entwickeln. HSA oder die kommenden Konsolen zeigen das mehr als deutlich. Sicherlich sind auch Verbesserungen bezüglich ILP nicht unwichtig. In modernen Systemen aber nur noch von sekundärer Bedeutung.

 

[ONH]

Kann man eine virtuelle Maschine auf einen Athlon starten und dem virtuellem Kind eine falsche CPU vorgaukeln?

Geht mit Vbox, kann man wenn in der vm konfigurationsdatei ein Komplatter CPU id String hinterlegt wird nur müsste man dazu ein passenden haben. Bei mir fürte das vor 1 oder so jahr dazu das die XP VM von einer Intel CPU ausging, aber durch das laufen lassen wurde das Notebook instabil & langsam solange die Vm lief mit XP ohne den Intel CPUID string gab es keine Probleme. Lag wohl an der CPUID welche nicht zu den Features der CPU passte.

@i-ich

Hast du den neusten poste im agner link angesehen, das AMD mehrfach benachteiligt wird eigentlich unabhängig von der verwendung von Intel libraries.
http://agner.org/optimize/blog/read.php?i=115#268

@ blub0815
Siehe link oben, solange intel oder amds eigene libaries verwendet werden werden die AMD Prozessoren länger brauchen als Intel vorausgesetzt das es bei anderen Funktionen gleich aussieht wie bei diesen beiden.
http://www.yeppp.info/home/yeppp-performance-numbers
Damit hat AMd schon im vorhinein mit darauf basierenden Benchmark ein Nachteil ohne das Intel bevorteilt würde. Da bleibt nur zu hoffen das AMD es mit HSA schafft das wie bei yeppp! Die beste zur Hardware passende implementation verwendet wird.

 

[mariahellwig]

Ich warte auf den Tag, an dem AMD die Tore schließen muss und die ganzen Intelfetischisten dann zu heulen beginnen, da alles so teuer geworden ist.
Den ganzen Leuten gehört dann eine ordentliche Tracht Prügel. Alleine schon dafür, weil sie einen Intellekt auf dem Niveau "Der Markt regelt sich selbst!" haben!

Das wird nicht passieren. AMD hat sie sich defacto heute schon aus dem Markt zurückgezogen. Ohne Konkurrenz verfällt Intel in einen Tiefschlaf und Innovationen bleiben aus. Diese Langeweile ist tödlich! Die Branche braucht Reize, wenn diese ausbleiben wird es schwer. Wie unsexy ein Desktop ist zeigen aktuell die Absatzzahlen eindrucksvoll. Darunter wird die gesamte Branche leiden, von den Chipfirmen über Hardwareanbietern, Softwareherstellern bis hin zu Onlineredaktionen.

Noch eindrucksvoller ist hingegen die Inkompetenz und Kurzsichtigkeit vieler Redakteure. So etwas löst bei mir nur noch blankes Entsetzen aus!

 

[miriquidi]

Sind Desktop-Computer so unattraktiv? Ist es nicht eher so, dass man auch mit einem Core-2-Duo + SSD im Büro gut zurecht kommt? Das die Rechner länger genutzt werden, ist ja nicht unbedingt nicht etwas schlechtes. Eher im Gegenteil, sofern man keine Chips herstellt.

Geht mit Vbox, kann man wenn in der vm konfigurationsdatei ein Komplatter CPU id String hinterlegt wird nur müsste man dazu ein passenden haben.

Nach etwas Suche bin ich hierauf gestoßen:
http://www.hardwareluxx.de/communit...-benachteiligt-7-a-699421-7.html#post15169510
Das 'Nicht-Intel-Flag' oder was auch immer kostet ca. 6 % bei einem K10 bei Cinebench R10 32 Bit. Das erklärt die Stagnation nicht unbedingt.
Hab aber weder eine VMware-Lizenz noch einen Bulldozer um das mit neueren CPUs zu überprüfen.

Ja toll, in den letzten Jahren von Generation zu Generation 5-10% oder so. Wahnsinnsleistung. Das merkst du überhaupt nicht im Alltag. Das hat AMD übrigens auch geschafft. Mein Llano ist pro Takt auch gute 5% schneller als sein Vorgänger.

Im Bereich dünner Notebooks ist es etwas drastischer. Den Unterschied zwischen einem Core-2-Duo SU9400 und den Ivy 17 W Modellen ist schon deutlich, mehr als Faktor 2. Wobei da auch viel über die TDP-Überschreitung des Core-i Modelle rausgeholt wird.
Gesetzt dem Fall, man könnte Microsoft davon überzeugen, dass Single-Thread-Aufgaben immer bevorzugt auf dem Kern#0 ausgeführt werden, könnte man beim Kabini-Nachfolger einen der vier Kerne mit schnelleren Transistoren ausrüsten, ohne an der Mikroarchitektur viel zu ändern. Schnelle Transistoren produzieren im Normalbetrieb bei 1,5 GHz einiges mehr an Leckstrom, aber mit 2,5 GHz+ im Single-Thread-Betrieb wäre das System dann schon gefühlt einiges flotter.
Für den Nachfolger reicht es jedenfalls nicht, den Großteil der Leistungssteigerung über mehr Kerne zu erreichen.

Sry, aber wer immer noch glaubt, singlethreaded hätte so viel Bedeutung, lebt in der Steinzeit.

Benutz du mal einen Atom N570 mit 2 + 2 (virtuellen) Kernen. Der wäre auch mit 8 + 8 Kernen kein Rechner, mit dem ich ein größeres Word-Dokument editieren wöllte. Einzig für BOINC wäre die Kiste echt nicht schlecht.

Du meinst bestimmtdie Ergebnisse aus Agner Fogs blog:
http://agner.org/optimize/blog/read.php?i=115#120

Nein, kannte ich noch nicht. Ist mir nur letztes Jahr zufällig aufgefallen, dass der Matlab FFT Befehl auf einem Sandybridge zum K8 taktbereinigt Faktor 2,x schneller läuft. So drastisch unterscheiden die sich im Fließkomma-Bereich sonst eigentlich nicht, eher Faktor 1,3 bis 1,5.

 

[FredD]

Gesetzt dem Fall, man könnte Microsoft davon überzeugen, dass Single-Thread-Aufgaben immer bevorzugt auf dem Kern#0 ausgeführt werden, könnte man beim Kabini-Nachfolger einen der vier Kerne mit schnelleren Transistoren ausrüsten, ohne an der Mikroarchitektur viel zu ändern. Schnelle Transistoren produzieren im Normalbetrieb bei 1,5 GHz einiges mehr an Leckstrom, aber mit 2,5 GHz+ im Single-Thread-Betrieb wäre das System dann schon gefühlt einiges flotter.

Ein hoher Aufwand, der sich innerhalb der Spezifikationen kaum rechtfertigen würde. Höhere Takte in dem angestrebten thermischen Rahmen sind hier nur durch ausgefeiltere Fertigung (z.B. fd-SOI) möglich.

Für den Nachfolger reicht es jedenfalls nicht, den Großteil der Leistungssteigerung über mehr Kerne zu erreichen.

Ich weiß ja nicht, warum du weiterhin und unnachgiebig behauptest, der Kabini-Nachfolger würde mehr Kerne erhalten?! Für Beema/Mullins ist dies nicht geplant, hier dürfte der HSA-fähige Speicherkontroller das eigentliche Feature werden.

 

[isigrim]

Ich verstehe nicht, was das ständige Singlethread gesülze im Kabini-Thread soll. 1. ist Kabini mit einem Atom N570 nicht mehr zu vergleichen. 2. ist das kein HighPerformance Produkt, sondern eben eine billig-APU.

Wir hatten schon festgestellt, dass ein Kabini deutlich gewinnen würde, wenn er einen ordentlichen Turbo hätte. Da das im A6-1450 schon erprobt wird, dürfte eine neue Revision das breiter mitbringen. Aber mit einem Kabini kann man nach Aussage derjenigen, die Tests damit gemacht haben, schon sehr ordentlich arbeiten. (bezieht sich auf den A4-5000). Der A6-5200 legt sogar nochmal ne Stange bei der CPU-Leistung drauf.

Nur was hilft das alles für AMD, wenn die Dinger nicht verbaut werden? Da könnten sie noch so schnelle super duper Singlethread-Kerne entwickeln....

Spoiler

Die meisten Rechenaufgaben (das bezieht sich auch aufs Rendern), sind via GPGPU deutlich effizienter zu lösen, als über eine hohe Singlethread Leistung. Und da will AMD korrekterweise hin. Stichwort HSA und OpenCL.
Intel hat bei OpenCL solange auf die Bremse getreten, bis sie selbst einigermaßen was in diesem Bereich zu bieten hatten und sie es als Industriestandard quasi nicht mehr verhindern konnten.
Intel trägt viel dazu bei, dass dieser Singlethread Nonsens so weitergefahren wird, wie bisher, liegt ja auch in ihrem Interesse, weil sie da Marktführer sind. Nur ist das nicht unbedingt gut für den Kunden. Und es führt auch langfristig nicht weiter. Das Ziel muss sein, soviel wie möglich zu parallelisieren.

 

[Complicated]

@FreD
Nur um präzise zu bleiben: meinst du einen hUMA fähigen Speichercontroller? Oder meinst du ein anderes, noch nicht bekanntes Feature von HSA, welches einen neuen Speichercontroller benötigt? Denn soweit ich weiss ist schon Llanos Speichercontroller HSA-fähig.

 

[Opteron]

Denn soweit ich weiss ist schon Llanos Speichercontroller HSA-fähig.

Hmm nö, wie kommst Du darauf? Llano hat 2 Speicherkontroller, einen für GPU einer für CPU. Bei HSA gibts nur noch einen.

 

[mariahellwig]

Der wäre auch mit 8 + 8 Kernen kein Rechner, mit dem ich ein größeres Word-Dokument editieren wöllte.

Mit aktueller Software vielleicht nicht. Wenn aber alle Rechner so ausgestattet wären, müsste Microsoft handeln und den Code anpassen.
Und, sie würden eine Lösung finden, da bin ich mir sicher. Ähnlich die Ausgangslage bei den neuen Spielkonsolen. Viele, wenn auch IPC-schwache Kerne.
Die Entwickler müssen erst mal umdenken, aber sie werden eine Lösung finden. Mit Sicherheit!

IPC-starke CPU's ist etwas bequeme Säcke. Von denen sind aber sowieso keine Innovationen zu erwarten. Sich ständig mit dem IPC zu befassen ist für mich eine Sackgasse, weil das Potential zu gering ist.

 

[FredD]

@FreD
Nur um präzise zu bleiben: meinst du einen hUMA fähigen Speichercontroller? Oder meinst du ein anderes, noch nicht bekanntes Feature von HSA, welches einen neuen Speichercontroller benötigt? Denn soweit ich weiss ist schon Llanos Speichercontroller HSA-fähig.

hUMA war gemeint (im Sinne älterer Roadmaps); der HSA-Begriff ist ja umfassender. So unbekannt ist das darauf folgende, geplante, große HSA Feature übrigens auch nicht: graphics preemption & GPU context switch, siehe u.a. http://www.planet3dnow.de/vbulletin...y-Nachfolger?p=4562161&viewfull=1#post4562161.

 

[Complicated]

Hmm nö, wie kommst Du darauf? Llano hat 2 Speicherkontroller, einen für GPU einer für CPU. Bei HSA gibts nur noch einen.

Ich komme darauf weil Llano der erste Fusion (=HSA) Chip war und Onion und Garlic (RMB und FCL) eingeführt hat. Das ist HSA Fähig.
Und ich frage nach weil mitlerweile immer mehr Leute hUMA gleichsetzen mit HSA.

edit:
Ich habe jetzt wiklich googlen müssen - Llano hat einen Speichercontroller:

 

[Opteron]

Ich komme darauf weil Llano der erste Fusion (=HSA) Chip war und Onion und Garlic (RMB und FCL) eingeführt hat. Das ist HSA Fähig.
Und ich frage nach weil mitlerweile immer mehr Leute hUMA gleichsetzen mit HSA.

Hmm also ob HSA = Fusion .. hmhm... gut wenn mans nur unter "heterogene system arch." liest, kann mans gelten lassen, immerhin gibts auch schon Zero-Copy, besser als nix.
Aber ohne huma ists irgendwie langweilig

edit:
Ich habe jetzt wiklich googlen müssen - Llano hat einen Speichercontroller:

Frage: Wenn die Grafik korrekt wäre, wieso bräuchte man dann Fcl und RMB?

Die hier stimmt:

(und es wird auch gleich die Frage beantwortet, für was RMB/Fcl gut sind )

Zwar Trinity, aber von Llano hat sich da nicht viel geändert. Fcl und RMB wurden nur breiter, wenn ich mich recht erinnere.

 

[nazgul99]

ThinkPad Edge E145 ohne OS, €349 (nicht lagernd), zur Zeit mein Lieblingsthema Leider auch diese Version noch nicht mit A4-5000, aber so langsam kommen die verschiedenen Varianten auf den Markt. Das einzige E135 ohne OS, das bei Notebooksbilliger.de noch gelistet wrid (dort auch das E145), kostet mit E2-2000 übrigens ebenfalls €349. Als die Variante mit E2-1800 vor Kurzem auslief, war es ja kurzfristig für €289 zu haben, ist aber nun anscheinend nicht mehr zu bekommen (noch 2 Listungen ohne Lagerestand). Das E135/E2-2000 ist bei Cyberport und CU übrigens für €319 zu haben, den Preis darf man für das E145 dann wohl auch bald erwarten. Wie gesagt alles jeweils die Version ohne OS.

 

[Complicated]

Frage: Wenn die Grafik korrekt wäre, wieso bräuchte man dann Fcl und RMB?

Gute Frage
Aber wie gesagt, es braucht eben keinen einheitlichen Memorycontroller um HSA Status zu haben. hUMA ist sicherlich eines der interessantesten Features, doch man sollte nicht vergessen welche Beschleunigungen schon mit Trinity möglich sind bei entsprechendem Code.

 

[wosch666]

ThinkPad Edge E145 ohne OS, €349 (nicht lagernd),

fein, fein.
Dann gibt es noch Hoffnung

 

[erko]

Nicht auf Haswell, nur auf Prozessoren, die das native intel(tm) compiler flag unterstützen.
Wenn sämtliche Performance-steigernde Befehls-Erweiterungen (SSE, AVX, udg.) nur auf Intel-Hardware unterstützt werden, nicht aber auf anderer Hardware, sollte man sich mal überlegen, was man mit so einem Benchmark eigentlich "misst", falls dies überhaupt das Ziel jenes Benchmarks ist, entlang gängiger Messtheorie ein möglichst hohes Maß an Reliabilität, Validität und Objektivität an den Tag zu legen.

Gibt es dazu eine sichere Quelle? Es kommt immer als Ausrede rüber. Immer wenn ein Benchmark nicht gefällt, weil AMD weit zurückliegt, kann man die Uhr danach drehen und es wird laut Intel optimiert geschrien. Der Phenom damals hat sich ganz normal verhalten, Bulldozer liegt es weniger wegen der starken FP Nutzung logischerweise. Von Wilfried Behne, einem Maxon Programmierer:

Just a few remarks regarding CineBench as some people seem to draw their conclusions from conspiration theories instead of facts:

1. CineBench 11.5 is based on CINEMA 4D (a professional 3D software package, consisting of several million lines of code). There is no special code tuned for benchmark purposes (or for a specific vendor), there are no special benchmark libraries; to be more precise: Except of the ability to save scene data, this is the production code.

2. CineBench 11.5 requires SSE2 compatible cpus. There is no differentiation between Intel or AMD cpus (the compilers are set to create SSE2 code without creating jump code for different cpus or cpu vendors).

3. The CineBench 11.5 Windows version uses ICC (the OS X version GCC 4.2), as these have been the compilers creating the fastest code at that time (end of 2009) for these platforms - independent of the cpu vendor. To be more specific: With the (SSE2) compiler setting used in CINEMA 4D and CineBench 11.5, the speed advantage of ICC over MSVC (roughly 15-20%) has been slightly bigger on AMD cpus than it was on Intel cpus.

4. While OpenMP is used on Windows in some parts of the app, there is no use of it in the rendering (that 's benchmarked and that people refer to when comparing results).

5. People who still think that CineBench prefers a specific vendor, might check what happened when the first Bulldozer CineBench results leaked. Despite of what some fanboys said before the launch (of this cpu), the CineBench results have been pretty accurate in picturing the strengths and weaknesses of this cpu.

realworldtech.com/forum/?threadid=135978&curpostid=136025

 

[isigrim]

Das mag ja für 11.5 gelten. Aber es ging um CB10 und dann noch 32bit.

 

[mariahellwig]

Gibt es dazu eine sichere Quelle? Es kommt immer als Ausrede rüber. Immer wenn ein Benchmark nicht gefällt, weil AMD weit zurückliegt, kann man die Uhr danach drehen und es wird laut Intel optimiert geschrien. Der Phenom damals hat sich ganz normal verhalten, Bulldozer liegt es weniger wegen der starken FP Nutzung logischerweise. Von Wilfried Behne, einem Maxon Programmierer:

So etwas ist nicht nur eine Frage von Compilerflags, sondern auch des Programmablaufs, int oder fp lastig.
Bulldozer kommt mit int-lastigem Code deutlich besser zu recht als mit fp-lastigem. Da Cinebench sehr fp-lastig, die Masse der Software aber int lastig ist, muss man sich mal ernsthaft fragen, warum dieser Benchmark so eine Bedeutung erlangt hat. Persönlich ignoriere ich diesen Benchmark, weil er in der Praxis vollkommen belanglos ist.

Betrachtet man Reviews von AMD-Produkten trifft man auf stirnrunzelnde Autoren, "der Cinebench ist so bedenklich schwach..." und man glaubt es mit einer großen Katastophe zu tun zu haben. Sieht man sie sich dann Bewertungen zu den den Produkten bei Amazon an, erhält man oft ein ganz anderes Bild. Man glaubt es kaum die Leute sind hochgradig zufrieden!!! Und das mit dem Cinebench-Ergebnis!!! Ja, spinnen die denn

Ist es nicht eher so, dass man auch mit einem Core-2-Duo + SSD im Büro gut zurecht kommt?

Ich habe auch noch so ein Gerät. Die Rechenleistung reicht für viele Tätigkeiten aus. Ich vermisse lediglich eine aktuelle GPU.
Da die Hardwarebeschleunigung im Browser nicht funktioniert, wirkt vieles doch sehr ruckelig. Videos verursachen sofort eine 100% Auslastung der CPU mit dem zu erwartenden Hochdrehen der Lüfter. Ich frage mich dann immer warum viele so CPU-fixiert sind.

 

[nazgul99]

Das hat auch Andreas Stiller schon nachgewiesen, indem er den Intel-Copiler patchte und die damit kompilierte SPEC-Suite somit auf AMD-Prozessoren deutlich schneller lief, auf Intel-CPUs jedoch nicht. Das ist aber leider schion eine ganze Weile her, er hat scheinbar keine Lust mehr, immer dem selben Thema hinterherzurennen Seit der neuesten Major-Version ist der Intel-Compiler nun nichtmehr "diskriminierend" gegen AMD-CPUs, auch eine Folge der Kartell-Prozesses. Das Problem ist, dass sehr häufig auch die Intel-Performance-Libraries eingesetzt werden und die schalten ihre Optimierungen nach wie vor nur für Intel-CPUs frei. Alles aus dem Gedächtnis nach Geschriebenem von Andreas Stiller, c't.

---------- Beitrag hinzugefügt um 15:54 ---------- Vorheriger Beitrag um 15:48 ----------

Der einzige Compiler und Libs, mit deren Hilfe auch für AMD-CPUs so gut wie möglich (automatisch) optimiert wird, sind jene von der Portland Group, die ist aber leider Ende Juli 2013 von Nvidia gekauft worden. Man muss nicht lange raten, für welchen Zweig Nvidia wohl kein Entwicklungsgeld mehr für Compiler- und Lib-Optimierungen mehr wird "verschwenden" wollen. Aber immerhin hat AMD mittlerweile ja auch seine eigenen Perf-Libs, man kann allerdings ziemlich sicher sein, dass die nur selten in Mainstream-Software eingesetzt werden. Sie sind wohl eher im HPC-Software-Feld anzutreffen.

Alles Gesagte aus dem Kopf (bis auf das PGI-Übernahme-Datum aus der englischen Wikipedia), ich hoffe ich bring nix durcheinander.

 

[i-ch]

@i-ich

Hast du den neusten poste im agner link angesehen, das AMD mehrfach benachteiligt wird eigentlich unabhängig von der verwendung von Intel libraries.
http://agner.org/optimize/blog/read.php?i=115#268

Nein. Ehrlich gesagt ich arbeite nicht in der Branche. Mich interessiert das ganze nur Hobbymäßig und im Augenblick habe ich keine Zeit dafür. Ich musste nur als ich versucht habe die Aussagen von Miriquidi zuverstehen an diesen Blog denken. Ich dache er meinte diesen, nur das er die Adresse vergessen hat. Das geht mir ja auch so, das ich die Seiten zu den Aussagen vergesse. Zumal zeigt die Seite ja auch wie Vorsichtig man mit det veröffentlichen Benchmarkergebnisse sein muss. Es gibt ja viele Stellschrauben. Auf die Stelle fallen mir nebendem Compiler-Flag speziellen Befehlen, durch Speichergroße oder Geschwindigkeitausnutzung vom Cache, RAM odder Platte, Rechenwiederholungen.

 

[mariahellwig]

Es liegt in der Natur der Sache das versucht wird da zu manipulieren, darüber sollte man sich immer im Klaren sein. Über das Ausmaß lässt sich sicherlich streiten.
Man sollte Benchmarks deshalb nicht überbewerten.

Wir haben gestern einen Server aufgesetzt, bei dem sich die Strategen im Vorfeld endlos die Köpfe heißgeredet haben. Intel oder AMD. Jetzt ist ein Opteron geworden, seine durchschnittliche Auslastung liegt mal gerade bei 8%. Also was soll das alles.

 

[i-ch]

Die Benchmarkproblematik sollte man nicht unterschätzen. Für uns "informierten" Privatleute sind die Benchmarks ein lästiges Übel. Man kennt die geringe Aussagekraft von dessen Werten. Aber diese werden seit in den öffentlichen Ausschreibungen nicht mehr direkt nach Intelprozessoren verlangt werden darf, benötigt um weiterhin zu bewerkstelligen das der "richtige" Prozessorlieferant genommen wird.

 

[nazgul99]

Da im Businessbereich nix neues mit AMD mehr kommt (bis auf verschwindend wenige Smallbusiness-Modelle wie das E145) und die alten Modelle verschwinden, spielt AMD in den Ausschreibungen eh keine Rolle mehr. Bei Servern sieht's nicht besser aus.

Beim einzigen AMD-basierten Business-Notebook mit Docking-Port, dem HP 6475b, verschwinden übrigens grad die Modelle mit 1600x900-Auflösung (eins hat noch über 20 Listungen, sind aber sehr ausgedünnt und zuvor gabe es noch deutlich mehr Modelle mit A6 und hoher Auflösung), das einzige Modell mit A8 ist schon verschwunden (nur noch eine Listung). Es wurde zuletzt für unter €600 verramscht Es gab ja auch keine Ankündigung für das Gerät mit Richland, im Gegensatz etwa zum U38N (war zumindest ausgestellt), wo es immerhin ein passendes BIOS-Update gibt, aber immernoch kein Produkt im Handel oder Richland-Angaben in den Asus-Specs. Aber das gehört ja auch eigentlich in den Trinity- oder Richland-Thread.

Edit: U38N-Link

 

[gruffi]

Im Bereich dünner Notebooks ist es etwas drastischer.

Nö, da ist es genauso. Sind schliesslich die gleichen Architekturen. Wovon du jetzt redest hat nichts mehr mit pro Takt zu tun, sondern schliesst Taktsteigerungen durch bessere Fertigungen, optimierte Designs und aggressivere Stromsparmechanismen mit ein. Da legt AMD ja auch kontinuierlich zu. Selbst innerhalb der gleichen Fertigung, siehe A10-4600M vs A10-5750M. Pro Takt ist Intel mit Atom jedenfalls sogar deutlich abgefallen. Da war selbst der P-M vor 10 Jahren schneller.

Benutz du mal einen Atom N570 mit 2 + 2 (virtuellen) Kernen. Der wäre auch mit 8 + 8 Kernen kein Rechner, mit dem ich ein größeres Word-Dokument editieren wöllte.

Klar, Atom ist 'ne Krücke. Was anderes behauptet ja auch keiner. In-Order ist mMn für Client Rechner, egal ob Desktop oder Notebook, einfach ungeeignet. Das funktioniert vielleicht, wenn du extreme Taktraten bei vergleichsweise geringem Energiebedarf fahren kannst. Mir ist da aber kein Ansatz bei Mobilprozessoren bekannt. In-Order + extreme Taktraten kenne ich maximal von IBM. Das sind dann aber auch stromhungrige Serverprozessoren. AMD nutzt sowieso kein In-Order. Selbst der kleine Jaguar ist deshalb pro Takt teils doppelt so schnell oder schneller als Atom. Das ist 'ne ganz andere Hausnummer. Mittlerweile hat das ja auch Intel eingesehen und nutzt beim zukünftigen Atom wieder OoO, wenn auch erst mal in beschränktem Umfang.

Gibt es dazu eine sichere Quelle? Es kommt immer als Ausrede rüber. Immer wenn ein Benchmark nicht gefällt, weil AMD weit zurückliegt, kann man die Uhr danach drehen und es wird laut Intel optimiert geschrien. Der Phenom damals hat sich ganz normal verhalten, Bulldozer liegt es weniger wegen der starken FP Nutzung logischerweise. Von Wilfried Behne, einem Maxon Programmierer:

Erst mal spricht er von R11.5. R10 ist eine andere Geschichte. Dort muss man sich in der Tat fragen, ob AMD zumindest in der 32-bit Version irgendwelche SSE Instruktionen sieht oder maximal mit x87 abgespeist wird. In R11.5 wurde das ja gar nicht angezweifelt. Zudem muss Maxon da auch nichts gross einstellen. Sie nutzen den Intel Compiler (ICC) samt der dazugehörigen Runtime. Das reicht schon völlig aus, damit Nicht-Intel Prozessoren benachteiligt werden können. Der ICC hat diesbezüglich einen schlechten Ruf. Warum, wieso und weshalb wurde hier schon oft genug diskutiert. Früher hat Intel teils mit dem Vendor String, welcher sich über CPUID abfragen lässt, beschissen. Gab dazu mal ein schönes Beispiel anhand des VIA Nano, wo man diese Kennung ändern konnte, was man normalerweise nicht kann (#1). Mittlerweile macht es Intel nicht mehr so offensichtlich. Gibt ja aber immer noch herstellerspezifische CPUID Funktionsbereiche, mit denen man genügend Unsinn anstellen kann. Es ist also mitnichten eine Ausrede, weil einem Ergebnisse nicht gefallen. Für die unlauteren Praktiken von Intel gibt es hinreichend Ungereimtheiten und Nachweise.




Zu HSA, dies ist lediglich ein übergeordneter Begriff für eine spezielle Infrastruktur. HSA bedingt eigentlich kaum konkrete Features. Im PDF wird für HSA Kompatibilität folgendes erwähnt:

1.5. Implementation Components

An HSA implementation is a system that passes the HSA Compliance Test Suite. It consists of:

• A heterogeneous hardware platform that integrates both LCUs and TCUs, which operate coherently in shared memory.
• A software compilation stack consisting of a compiler, linker and loader.
• A user-space runtime system, which also includes debugging and profiling capabilities.
• Kernel-space system components.

Insofern kann man durchaus bereits Llano als HSA-fähig betrachten. Darüber hinaus definiert HSA Konzepte, wie einen gemeinsamen Adressraum (Stichwort hUMA), die die Funktionalität verbessern sollen, aber nicht verpflichtend sind.

 

[Markus Everson]

Die Benchmarkproblematik sollte man nicht unterschätzen. Für uns "informierten" Privatleute sind die Benchmarks ein lästiges Übel. Man kennt die geringe Aussagekraft von dessen Werten. Aber diese werden seit in den öffentlichen Ausschreibungen nicht mehr direkt nach Intelprozessoren verlangt werden darf, benötigt um weiterhin zu bewerkstelligen das der "richtige" Prozessorlieferant genommen wird.

Was für eine wunderschöne Dolchstoßlegende! Ich finde es immer wieder spannend wie sich die einfach gestrickten Menschen die Ausschreibungsverfahren vorstellen und dabei in Gedanken ihren eigenen IQ (einstellig) den Ausschreibenden unterstellen.