News AMD: „Excavator“-Kerne mit „Carrizo“ schon im Dezember

@Herdware

Naja, das die CPUs ihre Leistung teils nicht ausspielen können ohne ein erneutes Kompilieren ist aber kein auf AMD beschränktes Problem. Intel hatte es unlängst beim Start von Haswell. Die meisten Reviews waren von sehr geringen Zuwächsen enttäuscht während eine kleine Minderheit dank mit AVX2 kompilierten Benches +70% sich geradezu überschlagen haben.
Oder älter, als Intel mit Hyperthreading angefangen hat war dessen Vorteil kaum über die einfachen Benchmarks für die Massen darstellbar.

Insofern hat AMD ein übliches Risiko auf sich genommen.


@calluna

Also die Intel IGPs können bereits für Computing genutzt werden und auch wenn AMD auf die HSA Marketing schlägt wie blöde, Intel ist auf diesem Gebiet in Reichweite. Wenn HSA also wirklich mal Verbreitung findet und wichtig ist kann Intel ganz bequem sagen "bin schon da". Wobei sich dieses "bin schon da" dann auf die Verfügbarkeit der Technologie als auch auf die kombinierte CPU+GPU Performance bezieht.
 
Zuletzt bearbeitet:
Piktogramm schrieb:
Oder älter, als Intel mit Hyperthreading angefangen hat war dessen Vorteil kaum über die einfachen Benchmarks für die Massen darstellbar.

Genau sowas meine ich ja. Es hätte sich damals auch garantiert niemand einen Pentium4 gekauft nur weil er HT unterstützt. Es war ein bei gewissen Modellen Extra-Feature oben drauf (das manchmal etwas gebracht hat und meist nichts) und anders wäre Intel es wohl auch nicht los geworden.

Ich sage auch nicht, dass Intel es immer richtig gemacht hat und AMD falsch. Wie schon erwähnt, hat Intel sich bei Pentium Pro damals extrem in die Nesseln gesetzt und AMD hat bei Athlon64 alles richtig gemacht. Um so mehr hat es mich bei Bulldozer gewundert, dass AMD diese Lektion scheinbar wieder vergessen hatte.
Wobei es wohl eher so war, dass besonders die ersten Zambezi-FX-CPUs einfach nicht so geworden sind, wie AMD es sich vorgestellt hatte, was zumindest teilweise auch am problematischen Fertigungsprozess lag. Mit 5GHz und weniger Verbrauch hätten die selben CPUs seinerzeit ziemlich gut ausgesehen. Auch mit schlecht optimierter Software.
 
Die neuen „Excavator“-Kerne werden als letzte Ausbaustufe das Modulkonzept bieten, bei der Fertigung bleibt jedoch alles beim alten.
Nach meinem Verständnis ist das das Finale der Modulbauweise und danach kommt wieder etwas, was man als "richtigen" Kern bezeichnen kann.
 
deo schrieb:
Nach meinem Verständnis ist das das Finale der Modulbauweise und danach kommt wieder etwas, was man als "richtigen" Kern bezeichnen kann.

Es gibt von Bulldozer nur die offizielle Ausbaustufe bis Excavator. Danach kommt die Zen-Architektur (wobei der Name hier nicht von AMD bestätigt ist, sondern von einem Gespräch rausgelauscht wurde) und wie die aussieht, weiß keiner. Es gibt wie gesagt nur das Interview von Jim Keller, wo er davon spricht, dass sein Team (das übrigens zeitgleich auch das ARM Design K12 entwickelt) das beste aus Puma und Bulldozer vereinen soll und dass man auch durch die ARM Architektur inspirieren lässt.

http://www.youtube.com/watch?v=SOTFE7sJY-Q
 
Zuletzt bearbeitet:
Die ganz großen Neuvorstellungen sollen erst 2016 kommen.
Bis dahin wird noch viel orakelt.
 
pipip schrieb:
Man hatte wohl die Hoffnung, dass Bulldozer nicht nur bei Server sondern auch bei Desktop seine Stärken zeigt, das war aber nicht der Fall, wie wir alle wissen.
.
Wo hat denn der Bulldozer im Server-Segment seine Stärken gezeigt? Da sieht es seit 3-4 Jahren mindestens genauso zappenduster aus wie im Desktop-Segment.

Mit Nehalem- und Westmere-EP konnte man noch einigermaßen mithalten, spätestens bei Sandy Bridge EP hat man aber jedoch die Rücklichter nur noch sehr klein erkennen können. Mit Haswell-EP bewegen wir uns jetzt in Bereichen, wo wir von bis zu 100% Performance-Vorteil sprechen.

Und im Server-Segment gibt es wahrlich genug Software, die auf mehrere Kerne gut skaliert.

Das Prinzip bleibt immer gleich:

Miese IPC = hohe Taktrate
hohe Taktrate = entweder sehr gute Fertigung oder hoher Verbrauch

Da der 32 nm Prozess bei Global Foundries nun einmal keine 5 GHz 16-Cores bei 130 Watt TDP hergibt, wird man über kurz oder lang eben an diversen Schrauben drehen müssen, um wieder einigermaßen konkurrenzfähig zu werden.
 
Simon
Wo hat denn der Bulldozer im Server-Segment seine Stärken gezeigt? Da sieht es seit 3-4 Jahren mindestens genauso zappenduster aus wie im Desktop-Segment.

Hätte die erste Frage nicht gereicht ? Soviel ich mich erinnere, war Bulldozer anfangs Watt/Core und Preis/Leistung ziemlich gut aufgestellt. Sonst gebe ich dir recht, hier kann ich nur das sagen, was ich im Forum so mit bekommen habe.

Btw der zweite Satz ist meiner Meinung nach völlig sinnlos und dann auch wieder nur verallgemeinert. Versteh mich nicht falsch, er ist nicht falsch, da sich seit paar Jahren nicht viel gemacht hat, bzw seit Vishera Release. Was aber ca 2 Jahre her ist und nicht 3-4 Jahre. Sonst, der Satz ist reine Polemik, nichts anders. Ich will dich nicht bloßstellen, aber es ist einfach nur mehr ermüdend, weil man in AMD Threads nur mehr solch einen Schreibstil zum Lesen bekommt.
Verallgemeinerung bis zum gehen nicht mehr, es nervt einfach nur mehr total. Jeder AMD Thread wird innerhalb wenigen Sekunden innerhalb den ersten 20 Post von den selben Leuten geflutet, obwohl jene selbst wahrscheinlich weder AMD CPU noch GPU haben oder je ein Produkt von denen gehabt haben.

Es ist wie dieser Satz :
Piktogramm schrieb:
Ansonsten, der Athlon64 war so gut weil Intels Netburst richtig schlecht war.

Was zum Beispiel total belanglos ist. Denn wo ist nach der Logik der Unterschied zu jetzt ? Wie oft wurde von Leuten Bulldozer mit Netburst verglichen ? Also kann man ja genauso sagen, SB und aktuelle Generation schneiden optisch deshalb so gut ab, weil AMD's Bulldozer so richtig schlecht in der Disziplin war.
Aber im Gegensatz, wurde Netburst zum Beispiel nie in Notebooks verbaut. Carrizo ist sogar ein SoC mit Bulldozer.

Die Vergleiche hinken alle immer wieder und es ist anstrengend, das immer wieder zu hinterfragen.

Somit Wirkung und Ursache. Da AMD Komodo gestichen hat, weil man zu der Zeit richtig schwer hatte. 3 CPU Architekturen, GPU Architekturen, dann noch der Prozess der Auslagerung von GF (und der Rückstand von GF). Dann Probleme mit dem 32nm SoI Verfahren, der bei den APUs nicht hingehaut hat und bei den Bulldozer nicht die erwarteten Takte einhalten konnte ect.

Ob Rory Read es richtig gemacht hat, wird man sehen. Doch die Entscheidung, weniger Masken, diese länger auf den Markt und das Geld in eine komplette neue Plattform, zu einer Zeit wo GF wieder konkurrenzfähigen Prozess liefern kann, macht bis jetzt einen positiven Eindruck.

Mich würde mal eines interessieren, wo Intel jetzt stehen würde, wenn sie keinen 22nm FinFet Prozess hätten, sondern wegen irwelchen Problemen auf den Prozess hätten verzichten müssen und weiterhin nur Zugriff auf 32 nm hätten.

Aber man darf ja nicht vergessen, Intel hatte ja auch so seine Last zu tragen, nämlich die 1 Mrd Euro Strafe an AMD.
 
Zuletzt bearbeitet:
Simon schrieb:
Wo hat denn der Bulldozer im Server-Segment seine Stärken gezeigt?

Wer behauptet das denn? pipip spricht lediglich von der Hoffnung.

Da der 32 nm Prozess bei Global Foundries nun einmal keine 5 GHz 16-Cores bei 130 Watt TDP hergibt, wird man über kurz oder lang eben an diversen Schrauben drehen müssen, um wieder einigermaßen konkurrenzfähig zu werden.

Ich denke dass der Prozess bei Globalfoundries mittlerweile excellent ist, nur dass Bulldozer einfach aus vielerlei Gründen ineffizient und langsam ist.
 
Ein Kaveri-Nachfolger, der Hybrid-CF-fähig ist, z.B. mit einer 270x-GPU o.ä. wäre prima.
Findet ihr nicht?
 
smilefaker
Das Problem ist ja Piledriver doch nicht mal der ursprüngliche Piledriver ist, denn man doch mit Komodo in Planung hatte und ich glaube dass Excavator auch nur mehr das nötigste umgesetzt wurde, weil es da eher um die anderen Techniken bezüglich HSA ect geht.

Es gibt nur ein einziges Produkt, wo AMD momentan seinen Fokus auf X86 hat und das ist offensichtlich Zen. 2016 wäre doch ein super Einstieg.
14nm, man hat bereits einen großen SoC auf den Markt gebracht hat also die nötige IP. DDR4 ist verfügbar, HBM ist verfügbar. HSA ist fertig.

Man kann hier von unten auf komplett neuen Chip + Plattform auf den Markt bringen und hat keine Altlasten. Also wieso 2015 noch ein FX auf den Markt bringen, wo man wahrscheinlich noch 32nm SoI nützten müsste, weil 28nm für hohe Taktraten nicht ausgelegt ist ?

Hobojobo
Naja, wenn dann eher Carrizo und R9 285. Falls R9 285 wirklich HSA kann. Denn dann wäre diese Lösung auch für Notebooks sehr interessant.
 
pipip schrieb:
smilefaker
Man kann hier von unten auf komplett neuen Chip + Plattform auf den Markt bringen und hat keine Altlasten. Also wieso 2015 noch ein FX auf den Markt bringen, wo man wahrscheinlich noch 32nm SoI nützten müsste, weil 28nm für hohe Taktraten nicht ausgelegt ist ?

28nm in der derzeit genutzten Form für CPU+GPU Transistoren auf einem DIE erlaubt keine hohen Taktraten, weil man entweder den Prozess hin zu GPU Transistoren, oder hin zu CPU Transistoren optimieren kann. Für reine CPU könnte man da schon etwas erwarten.
HSA ist ja schön und gut, aber wieder wird die Software vernachlässigt. Oder was genau gibt es an HSA Soft momentan?
Wo ist der Nutzen der 50% sinnlosen GPU Transistoren?
 
pipip schrieb:
..., wurde Netburst zum Beispiel nie in Notebooks verbaut. ...
Nur der Detailverliebtheit halber: Es gab durchaus Netburst-Schlepptops. Ich erinnere mich zumindest an eines der ersten Desktop-Replacements von Medion, das einen Netburst-Celeron verwendete. Das Ding war aber zugegeben, trotz niedrigerer Lüfterdrehzahl, lauter als mein iBook G4 1,33 GHz - und letzteres hatte eine 30cm 7000 U/min Turbine von Delta verbaut. Insofern: Was du damit sagen willst, ist schon richtig, Netburst war nur für Schlepptops für taube geeignet.
 
MountWalker
Aber das waren doch Notebooks mit Desktop Sockel, oder irre ich mich ?
 
@pipip

Du sprichst sehr oft von HSA. Dass dieses bei APUs sehr effizient sein kann, kann ich mir vorstellen aber bei den Kombinationen von CPU und GPU, wobei der GPU per PCIe angebunden ist, habe ich meine Zweifel aufgrund der Latenz beim Datentransfer.

Wie sieht es in diesem Bereiche eigentlich mit Dokumentationen für Software Entwickler usw. aus? Wie ist der Entwicklungsstand bei den Compilern?

Dieses soll kein Angriff oder ähnliches sein.
 
@ pipip

HSA is Marketinggeblubber genau wie vieles von Intel genauso. Bitte
http://www.heise.de/newsticker/meld...-und-effizienter-Angriff-auf-AMD-2390225.html

Laut Intels GPU-Architekt Stephen Junkins sind Gen8-GPUs voll kompatibel zu DirectX 12 (derzeit Direct3D 11.2), OpenGL 4.3 und zum Mobil-Ableger OpenGL ES 3.1. Sie sollen nicht nur unter Windows, Mac OS und Linux laufen, sondern auch unter Android. Vor allem aber sollen sie für GPU-Berechnungen besser geeignet sein als ihre Vorgänger – dank Shared Virtual Memory, einem gemeinsamen L3-Cache und voller OpenCL-2.0-Unterstützung. Stephen Junkins rief daher auf die anwesenden Entwickler auf der IDF auf, mehr Compute-Berechnungen auf die neuen GPUs zu verlagern.

zu HSA gehört vieles, wie zB HUMA, aber bei Intel entwickelt sich das genauso weiter, nur wird das weniger an die Glocke gehängt. Normale Weiterentwicklung eben...
 
Hallo32 schrieb:
@pipip

Du sprichst sehr oft von HSA. Dass dieses bei APUs sehr effizient sein kann, kann ich mir vorstellen aber bei den Kombinationen von CPU und GPU, wobei der GPU per PCIe angebunden ist, habe ich meine Zweifel aufgrund der Latenz beim Datentransfer.

Wie sieht es in diesem Bereiche eigentlich mit Dokumentationen für Software Entwickler usw. aus? Wie ist der Entwicklungsstand bei den Compilern?
Der Punkt bei HSA und hUMA ist dass eben kein Datentransfer statt findet, sondern die CPU einfach mit den Daten im selben Speicher weiter rechnet. Eine HSA GPU die CPU Zugriff auf den GDDR5 Speicher zulässt würde die Latenzen enorm verringern.

Infos zu HSA: http://developer.amd.com/resources/heterogeneous-computing/
 
Natürlich findet da ein Datentransfer statt, die Berechnungen der CPU finden in der CPU statt... wirklich effizient ist das ganze nur bei den APUs, am besten so wie in den Konsolen. Was du anscheinend meinst ist das umkopieren von einem Speicher in den anderen, welches bei gemeinsam genutzten Speicher entfällt, wenn einfach nur die Zeiger umgeschrieben werden.
 
Zuletzt bearbeitet:
Daedal schrieb:
Der Punkt bei HSA und hUMA ist dass eben kein Datentransfer statt findet, sondern die CPU einfach mit den Daten im selben Speicher weiter rechnet.

Die Daten aus den globalen/shared Ram/Cache müssen jeweils in den ALU Registern der CPU/GPU kopiert werden und nach der Berechnung zurück. Bei Systemen, die nicht auf eine APU basieren, wird die Latenz des Zugriffes auf den globalen/shared RAM/Cache nicht für CPU und GPU identisch sein. Einer der Komponenten, wahrscheinlich GPU, wird im Vergleich langsamer sein.
 
Was will man mit solchen realitiv langsamen CPU´s (bitte weiter lesen!)?
Sie kosten zwar wenig, die Kosten für Gehäuse usw bleiben ohnehin gleich! ;)
Somit lohnt sich die Ersparnis kaum und man kann gleich ein Mittelklassemodell nehmen.
 
Zurück
Oben