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

[Opteron]

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.

Hmm, nö, eigentlich doch nicht, denn da steht doch:

A heterogeneous hardware platform that integrates both LCUs and TCUs, which operate coherently in shared memory.

Kohärenz des gemeinsam benutzten Speichers gibts aber doch erst ab Kaveri, denn dafür braucht man gemeinsame Adressen. Im alten System wars egal, da es ja 2 getrennte Adressbereiche im Speicherraum gab. Was zw. 3 und 4 GB (bei 1GB VRAM) passierte, interessierte die CPU nicht, da sie den Bereich nicht "sehen" konnte, ergo ist damit auch keine Kohärenz möglich.

 

[i-ch]

Ich habe keinen Ausschreibenden eine geringe Intelligenz unterstellt, sondern das die Benchmarkmanipulation benutzt werden um indirekt einen Hersteller vorzugeben. Direkt einen Vorgeben sollte nicht mehr möglich sein (Diskriminierungsgrundsatz). Ob dieses nun Ausschreibenden so gewollt ist oder sich aus dem auf dem Markt befindlichen Angebot heraus ergibt, weil man nur eine gewisse Leistung haben möchte, lasse ich dabei offen. wenn Benchmarkergebnisse als Kriterium für einen Kauf herangezogenwerden, wird es fast automatisch auf einen Intelprozessor hinausläuft. Das vertrakte daran ist dass, wenn man keine konkreten Prozessoren vorgeben kann, müssen andere Orientierunghilfen verwendet werden. Und das sind nunmal entsprechend Benchmark und minimale Werte.

In der öffentlichen Ausschreibung die ich mir mal durchgelesen habe ging es um mehrere Rechner für die Stadtverwaltung. Dort wurde detailiert aufgelistet, welche Eigenschaften der Rechner haben soll. Unter anderem wurde dort konkrete Zahlenwerte von bestimmten Benchmarks vorgegeben. Welche Benchmarks es genau waren, weiss ich nun nicht mehr aber es waren keine, die ich nicht kannte. Prinzipell ist das nicht verkehrt, denn eigentlich sind die Benchmarks gerade dafür da um die Unterschiedlichen Leistungen vergleichbar zu machen.

Die folgende Werte habe ich dem Trinity vs. Ivy Bridge im CPU-Test vom CB entnommen. Jetzt mal angenommen du verlangst einen Rechner mit einem Wert von 65000 Arithmetik Drystone bei SiSoft Sandra 2012 – CPU-Leistung. Dieser Wert wurde ausgewählt, weil der Prozessor, mit dem die gewünschten Programme ausprobiert wurden, 100000 Punkte bei einer Auslastung von 60% hatte. Dann kann kein AMD Prozessor der gleichen Preisklasse wie der entsprechene Intelprozessor mehr angeboten sondern muss einer höheren Preisklasse entnommen werden. Dementsprechend kann man keinen entsprechenden AMD A10-5800K oder AMD FX-4170 dafür nehmen, sondern müsste schon zu einer höheren FX Klasse greifen. Bei Intel würde schon ein Intel Core i3-2120 reichen. Wenn der höhere FX nicht so günstig wäre, würde das Beispiel mehr Sinn machen. Damit ist klar das der Rechner mit i3 angeboten wird. Vorallem dann wenn noch ein paar andere Benchmark aufgelistet sind die das ganze noch verstärken.
http://www.computerbase.de/artikel/prozessoren/2012/test-trinity-vs.-ivy-bridge-im-cpu-test/22/

Jemand anderes verlangt in Ausschreibungen immer nach Rechner, deren Netzteil einen Ausschalter haben. Er geht davon aus, dass diese Netzteile besser sind als die Netzteile ohne Schalter. Es gibt auch vom Ausschreibenden gewisse Lenkungsmöglichkeiten.

 

[miriquidi]

Zitat Zitat von miriquidi Beitrag anzeigen
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.

Wenn man vollständig zitierte, müsste man nicht ständig alles wiederholen... Schau dir das mal an:
Notebook-Check.

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.

Warum ist bei einem Atom Single-Thread-Leistung ein Hindernis, bei einem Jaguar aber nicht?

@mariahellwig: Mit einer perfekten-Software Welt hätte AMD diese Probleme nicht. Nur sind Programmierer faule Säcke. Schließe mich da ein.

 

[isigrim]

Weil der Atom eine deutlich niedrigere Singlethread-Leistung hat....? Also zumindest wenn man von Kabini ausgeht. Bei Temash bin ich immernoch unschlüssig und daher finde ich es ärgerlich, dass so häufig Temash in Subnotebooks wandert, statt Kabini. Offensichtlich nehmen die Ingenieursfähigkeiten der OEMs mit der Zeit ab....
Ich arbeite immer noch zwischendurch auf meinem Dual 1 Ghz Bobcat Netbook und dank SSD geht das echt gut, wenn nicht grad irgendwas im Hintergrund enorm CPU-Leistung frisst. Natürlich ist es immer schön, Leistungsreserven zu haben, wenn man mal was Rendern möchte oder komplexe Simulationen macht, aber das mache ich dann eher auf meiner Workstation. Zum Schreiben (dafür wurde die Kiste angeschafft) taugt der C50 schon super. Das gilt für das Atom-Netbook, das inzwischen sein Dasein hier in einer Schublade fristet nicht.

Zum (in-Order) Atom ist zu sagen, dass da die IGP grottig ist und so der CPU-Teil häufig mehr Last abbekommt. Das gilt für Surfen, Videos etc. Der Vergleich von meinem C50 zu einem N570 würde für mich daher immer zugunsten des C50 ausgehen.

 

[gruffi]

Hmm, nö, eigentlich doch nicht, denn da steht doch

Nö, eigentlich doch. Du bringst hier was gewaltig durcheinander. Ein gemeinsamer Adressraum ist doch keine Voraussetzung für Kohärenz. Es erleichtert zwar Kohärenz. Um nicht zu sagen, es impliziert Kohärenz. Notfalls kann Kohärenz aber auch über entsprechende Kopiermechanismen sichergestellt werden. In dem zitierten Text zur HSA Kompatibilität steht jedenfalls nichts von gemeinsamer Adressraum. Da steht nur gemeinsam genutzter kohärenter Speicher. Und das konnte eben auch schon Llano.

Im alten System wars egal, da es ja 2 getrennte Adressbereiche im Speicherraum gab.

Das ist nur die eine Seite der Medaille. Was Llano als VRAM benutzt hat, war in der Tat egal. Llanos iGPU konnte aber auch schon über den Fusion Control Link (Onion) auf den Hauptspeicherspeicher der CPU zugreifen, inklusive Kohärenz natürlich. Prinzipiell sind damit die Voraussetzungen für HSA Kompatibilität erfüllt. Insofern ist es nicht falsch, Llano als HSA-fähig zu betrachten.

Wenn man vollständig zitierte, müsste man nicht ständig alles wiederholen... Schau dir das mal an:

Sag ich ja, komplett andere Taktraten. Der SU9400 taktet mit lediglich 1,4 GHz, während der i7-4650U mit bis zu 3,3 GHz taktet. Daher auch die grossen Leistungsunterschiede. Taktbereinigt sind es dann doch nur 25%. Bei 5 Architekturgenerationen, die zwischen beiden liegen, macht das im Schnitt gerade mal 5% pro Generation. Wie schon gesagt, nicht mehr als Magerkost. Und genau davon sprachst du ja und darauf hatte ich geantwortet, die pro Takt Performance. Mehr Performance inklusive Taktsteigerungen ist wiederum ein anderes Thema.

Warum ist bei einem Atom Single-Thread-Leistung ein Hindernis, bei einem Jaguar aber nicht?

Ist die Frage rhetorisch gemeint? Falls nicht, es wurde doch schon alles beantwortet. Jaguar ist OoO und hat daher eine viel höhere Performance pro Takt. Und bei ähnlichen Taktraten ergibt das eben auch deutlich mehr singlethreaded Performance.

 

[bbott]

Zum (in-Order) Atom ist zu sagen, dass da die IGP grottig ist und so der CPU-Teil häufig mehr Last abbekommt. Das gilt für Surfen, Videos etc. Der Vergleich von meinem C50 zu einem N570 würde für mich daher immer zugunsten des C50 ausgehen.

Auch bei reinen CPU Benches war der Bobcat schon bis zu 80% schneller idR waren es etwa 60%, da Kabini nochmals ordentlich zugelegt hat ist ein Vergleich zu Intels InOrder absolut sinnfrei. Es auf die IGP zu schieben ist auch nur die halbe Wahrheit, oder warum sonst hat HTT beim Atom bis zu 50% mehr Performance gebracht?!

 

[amdfanuwe]

Nö, eigentlich doch. Du bringst hier was gewaltig durcheinander. Ein gemeinsamer Adressraum ist doch keine Voraussetzung für Kohärenz. Es erleichtert zwar Kohärenz. Um nicht zu sagen, es impliziert Kohärenz. Notfalls kann Kohärenz aber auch über entsprechende Kopiermechanismen sichergestellt werden. In dem zitierten Text zur HSA Kompatibilität steht jedenfalls nichts von gemeinsamer Adressraum. Da steht nur gemeinsam genutzter kohärenter Speicher. Und das konnte eben auch schon Llano.

Entweder versteh ich dich falsch oder du liegst nicht richtig.
Bei Kohärenz geht es darum, dass eine Speicheradresse einen eindeutigen Wert beinhaltet.
Wird der Speicher in den Cache geladen und dort verändert, ist der Wert der Speicheradresse nicht mehr gültig.
Greift nun eine andere Einheit auf diese Speicheradresse zu, liest sie einen ungültigen Wert.
Kohärenz bedeutet nun den Zugriff auf die ungültige Speicheradresse zu erkennen und den richtigen Wert aus dem Cache zu holen und weiterzugeben.
Das ist bei Llano meines Wissens nach nicht gegeben. CPU und GPU können aud den gemeinsamen Adressraum zugreifen, sie erkennen aber nicht, ob die Daten im Speicher gültig sind oder ob noch in irgend einem Cache die gültigen Werte stehen.
Da hilft dann nur aufpassen, dass der cache nach bearbeiten solcher Speicherbereiche mit gemeinsamen Zugriff der Cache zurückgeschrieben wird bzw. diese Bereiche als "non cacheable" in der MMU markiert werden.
Ist aufwändig und kostet Zeit.
Erst Kaveri erlaubt mit huma komplett kohärenten Speicher und erleichtert somit das Programmieren enorm.

 

[isigrim]

@bbott
Ich denke das Problem ist: welchen Bobcat vergleicht man da? Einen Ontario mit 1 Ghz oder einen Zacate mit 1,6 Ghz? Mir ging es darum, dass ich schon den 1 Ghz Ontario z.B. einem 1,5 Ghz Atom Dualcore vorziehen würde.
Der 1 Ghz Ontario kommt bei CB10 Singlethread (will ich nun nicht als Maßstab für Performance nehmen, aber als Anhaltspunkt) auf 663 Punkte, dagegen kommt ein Atom nur auf 509 Punkte. Einen Vergleich bei der Grafikleistung lassen wir mal lieber...
Einen Zacate kann man mMn schlecht mit einem Dualcore Atom vergleichen, der spielt in einer ganz anderen Liga, was die Leistung angeht.

 

[gruffi]

Kohärenz bedeutet nun den Zugriff auf die ungültige Speicheradresse zu erkennen und den richtigen Wert aus dem Cache zu holen und weiterzugeben.
Das ist bei Llano meines Wissens nach nicht gegeben.

Doch, ist es. Wie ich schon sagte, dafür ist der Fusion Control Link (Onion) zuständig. Damit landen Speicheranfragen der GPU in der gleichen Warteschlange wie Speicheranfragen der CPU Kerne. Was wiederum die Sicherstellung der Kohärenz ermöglicht. Ich würde empfehlen, den Artikel von David Kanter nochmal durchzulesen. Da wird es nochmal etwas ausführlicher erläutert.

Erst Kaveri erlaubt mit huma komplett kohärenten Speicher und erleichtert somit das Programmieren enorm.

Sicher. Das ändert aber nichts daran, dass bereits Llano HSA kompatibel ist.

 

[Markus Everson]

Ich habe keinen Ausschreibenden eine geringe Intelligenz unterstellt, sondern das die Benchmarkmanipulation benutzt werden um indirekt einen Hersteller vorzugeben.

Also nicht Dummheit sondern Absicht die ggf. zivilrechtliche Konsequenzen nach sich ziehen kann. Und den Hersteller vorzugeben ist das Ziel der Ausschreibenden weil....?

Ob dieses nun Ausschreibenden so gewollt ist oder sich aus dem auf dem Markt befindlichen Angebot heraus ergibt, weil man nur eine gewisse Leistung haben möchte, lasse ich dabei offen.

Ach, das läßt Du offen? Nachdem Du oben noch erklärt hast das die Benchmarkmanipulation benutzt werden um indirekt einen Hersteller vorzugeben? Magst Du Dich vielleicht mal für eine Dolchstoßlegende entscheiden?

In der öffentlichen Ausschreibung die ich mir mal durchgelesen habe ging es um mehrere Rechner für die Stadtverwaltung. Dort wurde detailiert aufgelistet, welche Eigenschaften der Rechner haben soll. Unter anderem wurde dort konkrete Zahlenwerte von bestimmten Benchmarks vorgegeben.

Das findest Du erwähnenswert? Ich würde es erwähnenswert finden wenn sich eine Ausschreibung findet in der keine derartigen Angaben drin stehen. Wie sonst soll man die Leistungsklasse wenigstens grob vordefinieren?

 

[nazgul99]

"Fully coherent memory between CPU & GPU": Erst 2013. Damit wird Kaveri gemeint sein ("GPU uses pageable system meory via CPU pointers").

Man kann natürlich weiter darüber streiten, dass dies bei Llano vielleicht schon ein bisschen koherent war, aber was wäre ein bisschen Koherent? Ein bisschen schwanger?

Die Grafik hier zeigt dasselbe in grün - möglicherweise mit ein paar Detailänderungen in den anderen Kästchen, hab ich jetzt nicht kontrolliert..

---------- Beitrag hinzugefügt um 17:40 ---------- Vorheriger Beitrag um 17:28 ----------

Hier nochmal mit APU-Genrations-Namen (unterste Grafik).

 

[amdfanuwe]

Doch, ist es. Wie ich schon sagte, dafür ist der Fusion Control Link (Onion) zuständig. Damit landen Speicheranfragen der GPU in der gleichen Warteschlange wie Speicheranfragen der CPU Kerne. Was wiederum die Sicherstellung der Kohärenz ermöglicht. Ich würde empfehlen, den Artikel von David Kanter nochmal durchzulesen. Da wird es nochmal etwas ausführlicher erläutert.

Danke für den Link, kannte ich noch nicht. Auf Seite 2 dieses:

The CPU sees GPU memory as uncacheable, so stores are sent to the write combining buffer. When the data is flushed from the WCBs, it goes across the Onion bus to the GPU.

The CPU is not intended to read from GPU memory and the performance is singularly poor because of the necessary synchronization. The CPU regards the frame buffer as uncacheable memory and must first use the Onion bus to flush pending GPU writes to memory.

Das ist, was ich ausdrücken wollte, der (L1,L2) Cache ist nicht kohärent mit der GPU verbunden.
Deshalb dürfen Daten des gemeinsamen Speichers nicht im Cache landen. Macht die ganze Sache langsam.
Onion ist im Grunde ein interner PCIe Bus. Für den Programmierer macht es bei Llano dann wohl keinen Unterschied, ob die GPU im Chip oder als Karte ausgelegt ist.

Bei Kaveri sollte es ähnlich aussehen wie bei Sandy. Vollen kohärenten Zugriff aller Parteien.

 

[Opteron]

Ein gemeinsamer Adressraum ist doch keine Voraussetzung für Kohärenz. Es erleichtert zwar Kohärenz. Um nicht zu sagen, es impliziert Kohärenz. Notfalls kann Kohärenz aber auch über entsprechende Kopiermechanismen sichergestellt werden. In dem zitierten Text zur HSA Kompatibilität steht jedenfalls nichts von gemeinsamer Adressraum. Da steht nur gemeinsam genutzter kohärenter Speicher. Und das konnte eben auch schon Llano.

Hmm also der Argumentation kann ich nicht folgen. Wieso willst Du was Kopieren, wenn es schon koherent ist? Ist das ist doch der springende Punkt. Du musst NICHTS extra per Hand kopieren. Wenn Du den Fall mit dem händischen Kopieren zulässt, dann ist alles und jeder koherent, auch der USB Stick der Oma, denn da könntest Du ja auch die Daten raufkopieren. Ne also das kanns wirklich nicht sein, wenn da steht coherent memory, dann meint dass die eingebaute, automatische Kohärenz, alles andere wäre Humbug.

Das ist nur die eine Seite der Medaille. Was Llano als VRAM benutzt hat, war in der Tat egal. Llanos iGPU konnte aber auch schon über den Fusion Control Link (Onion) auf den Hauptspeicherspeicher der CPU zugreifen, inklusive Kohärenz natürlich.

Hmm ich hab nur die eine Seite geannnt, da es die wichtig ist. Schauen wir einfach mal ins alte LLano PDF, da steht:

Llano introduces two new buses for the GPU to access memory:
–AMD Fusion Compute Link (ONION):
?This bus is used by the GPU when it needs to snoop the CPU cache, so is a coherent bus
?This is used for cacheable system memory

Hast also recht es gibt nen kohärenten Zugriff der GPU auf den CPU-Speicher. Aber die GPU kann auch machen was sie will:

–Radeon Memory Bus (GARLIC):
?This bus is directly connected tomemory and can saturate memory bandwidth, so is a non coherent bus
?This is used for local memory and USWC (uncached speculative write combine)

Quelle: http://amddevcentral.com/afds/assets/presentations/1004_final.pdf

Ergo es gibt keinen einen gemeinsamen und kohärenten Speicher, ergo Llano ist auch nicht HSA kompatibel.

 

[gruffi]

Das ist, was ich ausdrücken wollte, der (L1,L2) Cache ist nicht kohärent mit der GPU verbunden.
Deshalb dürfen Daten des gemeinsamen Speichers nicht im Cache landen. Macht die ganze Sache langsam.
Onion ist im Grunde ein interner PCIe Bus. Für den Programmierer macht es bei Llano dann wohl keinen Unterschied, ob die GPU im Chip oder als Karte ausgelegt ist.

Jetzt haust du aber was durcheinander. Der nicht cacheable Speicher läuft über das Garlic Interface, nicht Onion. Im Grunde läuft alles nicht kohärente über Garlic, alles kohärente über Onion.

Bei Kaveri sollte es ähnlich aussehen wie bei Sandy. Vollen kohärenten Zugriff aller Parteien.

Keine Ahnung, wie es bei Sandy Bridge ausschaut. Der kennt aber genauso wenig wie der aktuelle Haswell einen gemeinsamen Adressraum. Kaveri ist hier also schon einen Schritt weiter.

Hmm also der Argumentation kann ich nicht folgen. Wieso willst Du was Kopieren, wenn es schon koherent ist?

Wer hat das denn gesagt? Ich sehe niemanden. Es wurde gesagt, dass notfalls kopiert werden muss, um Kohärenz sicherzustellen. Ein gemeinsamer Adressraum ist also keine Voraussetzung für Kohärenz, wo natürlich nichts mehr kopiert werden muss.

Wenn Du den Fall mit dem händischen Kopieren zulässt, dann ist alles und jeder koherent, auch der USB Stick der Oma, denn da könntest Du ja auch die Daten raufkopieren.

Nein. Von "händischen Kopieren" hat ebenso keiner was gesagt. Bitte erfinde nicht schon wieder so viel! Die Hardware muss das natürlich von sich aus unterstützten. Ein USB-Stick tut das nicht.

Ne also das kanns wirklich nicht sein, wenn da steht coherent memory, dann meint dass die eingebaute, automatische Kohärenz, alles andere wäre Humbug.

Und was glaubst du, wie diese funktioniert? Richtig, da muss kopiert werden ohne gemeinsamen Adressraum. Nämlich wenn die aktuellen Daten im Cache sind. Dafür brauchen wir nicht mal eine iGPU. Da reicht bei Llano schon, wenn ein CPU Kern auf die Daten zugreifen möchte, die ein anderer Kern aktuell im L1 oder L2 hat.

"Fully coherent memory between CPU & GPU": Erst 2013.

Von "fully" steht aber nichts im HSA PDF bezüglich Kompatibilität. Da steht nur drin, dass kohärenter Speicher überhaupt vorhanden sein muss. Und das ist bei Llano der Fall. Oder mit anderen Worten, es steht nicht drin, dass kein nicht kohärenter Speicher vorhanden sein darf. Was ja auch nachvollziehbar ist. Das wäre nur eine unnötige Beschränkung. Wenn Kohärenz für eine spezielle Funktionalität nicht notwendig ist, kann man das Design an der Stelle weniger kompliziert und eventuell auch performanter gestalten. Insofern lass ich das mal an der Stelle nicht gelten. Es gibt jedenfalls einen gemeinsamen und kohärenten Speicher. Llano ist laut PDF also HSA kompatibel. Ob es auch so gewollt ist, ist eine andere Frage.

Übrigens, noch als kleiner Denkanstoss. Die Folie zuvor läuft unter der Überschrift "HSA FEATURE ROADMAP". Wenn Llano nix mit HSA zu tun hätte, dürfte er logischerweise auch nicht auf der Roadmap auftauchen. Llano ist einfach die erste HSA Generation. Kaveri lediglich die bis dato womöglich wichtigste.

 

[erko]

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.

Wer bencht schon die 32bit Version? Ich sehe 9% Rückstand beim CB11.5 und 8,5% Rückstand beim CB10 vom FX-8350 gegen i7-3770k. Dafür das Cinebench eher FP bevorzugt absolut nichts besonderes.

http://www.overclockers.com/wp-content/uploads/2012/10/oc-fx-8350-cb115.jpg
http://www.overclockers.com/wp-content/uploads/2012/10/oc-fx-8350-cb10.jpg

 

[gruffi]

Wer bencht schon die 32bit Version?

Das fragst du besser miriquidi. Das Thema kommt von ihm. Ich sagte ja selbst, dass 32-bit nicht mehr wirklich zeitgemäss ist.

 

[Woerns]

Interessante Gespräche - allerdings über Themen, die leider nicht unbedingt in den Kabini-Thread gehören.
Macht doch einen Thread auf mit z.B. dem Titel: HSA und seine Ausbaustufen.

Ich freue mich immer, wenn ich sehe, dass neue Beiträge in diesem Thread aufgetaucht sind. Immer in der Hoffnung, dass neue, Kabini beherbergende Modelle, vorzugsweise größere ThinkPad Edges, gesichtet worden sind. Und dann diese nicht enden wollende HSA Diskussion.
MfG

 

[Opteron]

Ok, hier gehts weiter:
Alles über/um HSA (aus dem Kabinithread).

 

[Markus Everson]

Ich freue mich immer, wenn ich sehe, dass neue Beiträge in diesem Thread aufgetaucht sind. Immer in der Hoffnung, dass neue, Kabini beherbergende Modelle, vorzugsweise größere ThinkPad Edges, gesichtet worden sind.

Die Wartezeit verkürzt das Lesen von [Laptopmag's bericht über das MSI-W20 3M mit A4-1200]. Wer lieber ein Streichholz anzündet statt die Dunkelheit zu verfluchen könnte sich dagegen überlegen ob [selber Löten] nicht doch zum schnelleren Erfolg führt.

(beide Links aus Semiaccurates Forum)

 

[bbott]

Wer lieber ein Streichholz anzündet statt die Dunkelheit zu verfluchen könnte sich dagegen überlegen ob [selber Löten] nicht doch zum schnelleren Erfolg führt.
(beide Links aus Semiaccurates Forum)

Dann müsste man nur noch die Leiterbahnen auf der Platine selber Ätzen, ein Gehäuse per 3D Drucker sollte dann auch Recht einfach gehen. Alles zusammen könnte schneller gehen als sein "Wunsch" Kabini-Gerät zu bekommen...

 

[blub0815]

Was ist eigentlich daraus geworden?

 

[miriquidi]

Weil der Atom eine deutlich niedrigere Singlethread-Leistung hat....? Also zumindest wenn man von Kabini ausgeht.

Genau das ist der Punkt. Ein E-350 oder Kabini arbeitet einen Thread wesentlich schneller ab als der alte Atom. Und den Faktor 2 merkt man deutlich, gut beim C-50 mag es nicht ganz Faktor 2 sein.
Mit perfekt parallelisierte Software ist der alte Doppelkern Atom übrigens gar nicht so übel, kommt einen E-350 ganz nah, mal etwas langsamer, mal schneller. Habe ja beide da - gefühlt liegen zwischen beiden trotzdem Welten.

Das Problem für AMD ist, dass dieses Single-Thread-Verhältnis von Atom zu Bobcat / Kabini sich so langsam aber sicher auch zwischen Kabini und den Core-Modellen einstellt. Die adressieren sicher unterschiedliche Preisbereiche, nur verdient AMD da unten recht wenig und muss aus der Nische raus.

Sag ich ja, komplett andere Taktraten. Der SU9400 taktet mit lediglich 1,4 GHz, während der i7-4650U mit bis zu 3,3 GHz taktet. Daher auch die grossen Leistungsunterschiede. Taktbereinigt sind es dann doch nur 25%.

Ich hasse das, aber naja:

Seit dem Core-2 war es eher die Kombination aus sparsamen Rechenwerken und kräftigem Turbo. Zumindest single-threaded.

Intel kann in ihren Designs einzelne Kerne hochtakten und die TDP auch mal sprengen, AMD nicht. Das muss AMD lernen. Kabini mit richtigem Turbo wäre um einiges flotter.

 

[Duplex]

Mich würde mal interessieren wie hoch die Leistungsaufnahme bei >2,5Ghz auf 4 Kernen wäre.
Anfang 2014 soll der Kabini Refresh kommen, mal sehen vielleicht kann AMD durch den "HPM" 28nm Prozess mehr rausholen als "HP" 28nm.
Ob es sich lohnt muss AMD wissen, gibt es inzwischen mehr Auswahl bei den Geräten mit Kabini APUs? Ich hab das Gefühl das Intel wieder die alten Mitteln eingesetzt hat damit AMD keinen hohen Absatz erreichen kann.

 

[Markus Everson]

Zitat von gruffi Beitrag anzeigen

Du zitierst gruffi, verlinkst aber auf einen Beitrag von opteron. Nanu..?

Bitte sag mir das der beginnende Schwanzlängenvergleich in einem anderen Thread stattfindet. Hier gehts um Kabini.

 

[FredD]

Das Problem für AMD ist, dass dieses Single-Thread-Verhältnis von Atom zu Bobcat / Kabini sich so langsam aber sicher auch zwischen Kabini und den Core-Modellen einstellt. Die adressieren sicher unterschiedliche Preisbereiche, nur verdient AMD da unten recht wenig und muss aus der Nische raus.

Du meinst die Nische, welche Intel (neben einer Reihe von ARM-Lizensnehmern) gerade mit Hochdruck in Angriff nimmt?

Intel kann in ihren Designs einzelne Kerne hochtakten und die TDP auch mal sprengen, AMD nicht. Das muss AMD lernen. Kabini mit richtigem Turbo wäre um einiges flotter.

Die Ingenieure bei AMD sind keine kleinen Kinder, die 'lernen müssen', zwischenzeitlich die TDP überschreiten zu lassen, um im Schnitt darauf zu liegen. Mit dem Kabini-Refresh dürfte sich deutlich mehr Taktfreudigkeit zeigen; beim Nachfolger können wir (nach eigener Spekulation) auch mit einer fortgeschritteneren Fertigung rechnen, welche von Grund auf höhere Takte (bei gleicher oder niedrigerer el. Leistung) ermöglicht. Aber die eigentliche Frage ist weniger technischer Natur, sondern vielmehr ökonomischer (Usability): Wozu mehr Rechen-Leistung, wenn mit, sagen wir, auf 2 GHz getakteten Jaguar Kernen bereits das Niveau "schnell genug" für OS und Mobil-Applikationen erreicht wird? Geht der Trend wirklich dahin, dass der Durchschnittsnutzer demnächst komplexe wissenschaftliche Simulationen auf dem Smartphone ausführen möchte?