Archiv verlassen und diese Seite im Standarddesign anzeigen : AMD - ARM Opterons
http://arstechnica.com/information-technology/2012/10/amd-announces-arm-based-opteron-cpus-due-to-launch-in-2014/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+arstechnica%2Findex+%28Ars+Technica+-+All+content%29
W T F
Skysnake
2012-10-30, 00:13:51
Naja, ein logischer Schritt bzgl dem Kauf von SeaMicro.
Viel spannender finde ich den Teil, dass die APUs what ever jetzt freigegeben werden, um mit IP-Blöcken von Kunden verschmolzen zu werden.
Man stelle sich mal nen Opteron mit Gemini-Network ON-DIE vor :biggrin:
Shink
2012-10-30, 06:23:25
Das kam jetzt dann doch überraschend für mich. Ich dachte, mit den 16 (Integer)-Kern-Opterons ist man ganz gut aufgestellt für "Cloud, Hosting, Big Data, Linux/Apache/PHP" und ähnlichem Gedöns.
AMD-APUs für mobile Devices würde ja jedem einleuchten. Das hier ist um einiges spannender...
Ailuros
2012-10-30, 07:28:58
W T F
ROFL :D
Uebrigens sollte jemand dem Author erklaeren dass NVIDIA in Tegra bis jetzt keine 64bit ARM CPU cores hat und das relevante Zeug von NV auch nicht bevor 2014 ankommt.
Nakai
2012-10-30, 09:24:36
Mhh, das hat AMD doch schon vor einiger Zeit auf irgendeiner Veranstaltung durchblicken lassen, dass man irgendwann auf ARM gehen könnte. Naja, dass man eher ServerARMs fertigt ist jetzt nicht so das, was ich erwartet hätte, aber besser als nichts.
robbitop
2012-10-30, 09:53:33
Wundert mich sehr. Ich hätte gedacht, die Bobcat-Architektur (inkl. aller Nachfolger) wäre dafür mehr als geeignet.
y33H@
2012-10-30, 10:30:54
http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9MTU5NTA3fENoaWxkSUQ9LTF8VHlwZT0z&t=1
Fabian_HT4U
2012-10-30, 11:23:01
Wundert mich sehr. Ich hätte gedacht, die Bobcat-Architektur (inkl. aller Nachfolger) wäre dafür mehr als geeignet.
Bobcat ist imho auch sehr gut geeignet. Ich erinnere mich dunkel, dass es seitens AMD sogar Pläne gab Bobcat in Mikro-Servern einzusetzen.
Vielleicht ist es aber auch ein Zeichen, dass sich AMD im Low-Power von Bobcat trennt und auf ARM umsattelt, sofern die Zusammenarbeit fruchtet. Man müsste dadurch eine Architektur weniger entwickeln, was Geld und Ressourcen spart...
Grüße
Fabian
Vielleicht ist es aber auch ein Zeichen, dass sich AMD im Low-Power von Bobcat trennt und auf ARM umsattelt, sofern die Zusammenarbeit fruchtet. Man müsste dadurch eine Architektur weniger entwickeln, was Geld und Ressourcen spart...
Na Kabini läuft schon im Labor. Trennen schaut also anders aus. Sieht eher danach aus, als ob sie 2 Kerne parallel anbieten werden, und eben nicht Geld und Resourcen sparen ...
Möglicherweise können sie aber auch den Kabini-Kern "verwursten", also doch Geld sparen, da sie nicht bei 0 anfangen müssen. Einfach den x86-Decoder gegen nen ARM-Decoder austauschen, noch ein paar Kleinigkeiten zur ARMv7/v6 etc. Kompatibilität anbauen, und schon könnte das fertig sein.
Einfach den x86-Decoder gegen nen ARM-Decoder austauschen, noch ein paar Kleinigkeiten zur ARMv7/v6 etc. Kompatibilität anbauen, und schon könnte das fertig sein.
Errr, so einfach ist das nicht.
Errr, so einfach ist das nicht.
Wo siehst Du die größten Schwierigkeiten? Ein ARM Decoder wäre durch die feste 32bit Instr.-Länge ja eher primitiv zu nennen. Also meinst Du dann den Anbau von alten Legacy Sachen?
Der Core an sich ist in vielen Teilen auch auf x86 ausgelegt (Adresseinheiten, Registerfiles, etc.)
Du kannst nicht einfach nen anderen Decoder davorpappen und es läuft. So funktioniert das nicht.
robbitop
2012-10-30, 11:50:31
Vor allem: welchen Zweck hätte das? ARM/x86/MIPS/PPC - das sind nur ISAs nach außen hin. Die selbst machen eine CPU noch lange nicht schnell, langsam oder stromsparend. Heutige SFF SoCs sind aus historischen Gründen ARM und sind natürlich auf low power ausgerichtet. Bei heutigen Fertigungsprozessen und Transistorzahlen ist der x86 Malus für die Decoder sicherlich zweitrangig. Genauso kann man aber auch, wie NVIDIA mit Denver, einen High Performance ARM Prozessor entwickeln.
Gerade bei Servern verstehe ich den Sinn nicht ganz. Ein Bobcatkern rennt mit wenigen Watt und x86 ist eh sehr verbreitet. Das macht nur Sinn, wenn man nochmal in einer keinere Größenordnung was Leistungsaufnahme angeht möchte. Die Frage ist, ob ein SFF SoC nochmal eine bessere Perf/W hat. Dann würde es Sinn ergeben.
Fabian_HT4U
2012-10-30, 12:01:04
Na Kabini läuft schon im Labor. Trennen schaut also anders aus. Sieht eher danach aus, als ob sie 2 Kerne parallel anbieten werden, und eben nicht Geld und Resourcen sparen ...
Möglicherweise können sie aber auch den Kabini-Kern "verwursten", also doch Geld sparen, da sie nicht bei 0 anfangen müssen. Einfach den x86-Decoder gegen nen ARM-Decoder austauschen, noch ein paar Kleinigkeiten zur ARMv7/v6 etc. Kompatibilität anbauen, und schon könnte das fertig sein.
Und wann soll Kabini kommen und wann ist ARMv8 soweit? Man hat noch nichts zu Nach-Kabini gehört und hier könnte imho durchaus ein Strategiewechsel geben. Ein Design teilweise zu tauschen macht, wie schon andere sagten, keinen Sinn.
Grüße
Fabian
Skysnake
2012-10-30, 12:24:18
Ähm..
Habt ihr alle DAS Schlagwort "FABRIC" übersehen?
Das ist ja eigentlich der ausschlaggebende Punkt für die ARM-Server. Irgendjemand bringt eh ARM-Server, das steht fest, also entweder überlässt man einem den Markt, oder man steigt halt selbst in diesen Markt ein.
Die Dinge müssen sich ja nicht gegenseitig ausschließen, sondern ergenzen. Gerade für nen File-Server brauchste oft nicht Unmengen an Rechenleistung. Man Differenziert halt seine Produktpalette stärker. Einsatzbereiche gibt es anscheinend genug, und so lange die Einnahmen größer sind als die Ausgaben passt die Sache.
AMD hat durch den Zukauf von SeaMicro offenbar die Chance gesehen, ein Problem recht kostengünstig zu lesen, das solche ARM-Kisten haben. Nämlich dass du relativ wenig Rechenleistung/Chip hast, und in einem normalen Design dann eben unglaublich viele Knoten hast, und das skaliert halt nicht unbedingt sonderlich toll und Interconnect ist auch durchaus ein gewichtiger Kostenfaktor.
Mit Ihrer "FABRIC" wollen Sie jetzt halt mehrere dieser ARM-CPUs bündeln. Das kann auf zweierlei Arten funktionieren. Auf der einen per MB/Backplane, wo man ein lokales Netzwerk hat, an dem dann auch die echten Netzwerkkarten hängen, das wäre dann so was wie ein Cluster-in-a-Box, oder halt Larrabee/KNC/KNF/MIC/XeonPhi stylisch, indem man alles auf einen großen DIE packt als Cluster-on-a-Chip.
Ich tendiere eher zu Lösung Nummer 1. So sind doch schon die aktuellen SeaMicro-Systeme aufgebaut oder???
Variante 2 wäre allerdings auch durchaus interessant.
Shink
2012-10-30, 12:28:03
Wundert mich sehr. Ich hätte gedacht, die Bobcat-Architektur (inkl. aller Nachfolger) wäre dafür mehr als geeignet.
Intel setzt für diese Anwendungszwecke auf ihren Atomunfall-Prozessor:
http://download.intel.com/newsroom/archive/Cloud_Infrastructure_Nirvava-Intel_Waxman_Structure-keynote.pdf
AMDs "Wimpy Core Servers" werden somit binär-inkompatibel zur Intel-Variante.
Gipsel
2012-10-30, 12:46:23
Habt ihr alle DAS Schlagwort "FABRIC" übersehen?Oder die Folie, auf denen ein ARM-Kern mit einer (x86er)-APU gekoppelt ist? AMD hat ja betont, daß der mit SeaMicro eingekaufte Freedom-Fabric ISA agnostic ist. ;)
Dazu kommt dann noch die Ankündigung vom letzten AFDS, daß man ARM und x86er in Hinblick auf das Virtual Memory Management kompatibel machen will, so daß die verschiedenen Kerne letztendlich (kohärent) auf den gleichen Speicher zugreifen können ...
Skysnake
2012-10-30, 12:52:59
Naja, das fand ich jetzt nicht sooo spannend, da wir das ja praktisch schon aktuell in den AMD-CPUs haben. Man kann ja auch auf AMD Maschinen ARM-Programme ausführen. Ein Schelm wer sich dabei einen Zusammenhang denkt ;)
Viel spannender ist doch, wie die Fabric genau aussieht. Ich hab dazu nicht wirklich was gefunden :(
Für High-I/O Sachen könnte das ziemlich interessant sein.
Gipsel
2012-10-30, 12:58:12
noch ein paar Kleinigkeiten zur ARMv7/v6 etc. Kompatibilität anbauenARMv8 ist automatisch mit ARMv7-A kompatibel. Das ist (ähnlich wie x64) mit zwei Betriebsmodi entworfen, der ARM32-Modus ist ARMv7-A kompatibel (und es werden insgesamt 3 ISAs unterstützt: A32, T32 [Thumb/Thumb2] und A64).
ARMv8 ist automatisch mit ARMv7-A kompatibel. Das ist (ähnlich wie x64) mit zwei Betriebsmodi entworfen, der ARM32-Modus ist ARMv7-A kompatibel (und es werden insgesamt 3 ISAs unterstützt: A32, T32 [Thumb/Thumb2] und A64).
Ja klar, aber ein Kabinikern ist ja nicht automatisch ARMv8 kompatibel. Das war so gemeint, dass Kabini sich eventuell recht einfach auf ARMv8 umtrimmen lässt (wg. 64bit, 128bit SIMD und Crypto), plus zusätzlcihem Aufwand / Kleinigkeiten für ARMv7, da man eben kompatibel sein muss und der 64bit Teil vom ARMv8 nicht reicht.
Aber Coda hat da ja noch einige Bedenken. Ich sehs jetzt weiterhin nicht sooo schlimm. Gut, dann muss man den Kern auch noch an die ARM Adressierung anpassen, z.B. auch die 64k Pages, aber das ist kein Unterschied wie Tag und Nacht. Bei den Registern seh ich auch wenig Bedenken, zwar sieht ARMv8 da doppelt soviele Register vor als AMD64, aber in Hardware haben die x64 Chips auch immer mehr Register wg. Register-Renaming implementiert. Außerdem ist das ganze doch auch ein synth-Design, da sind Änderungen einfacher zu implementieren, oder nicht?
Anders gefragt: Sollte AMD den ARM-Kern von Grund auf neu entwerfen und kann überhaupt nichts von Kabini wiederverwerten?
Shink
2012-10-30, 13:52:58
Habt ihr alle DAS Schlagwort "FABRIC" übersehen?
Mit Ihrer "FABRIC" wollen Sie jetzt halt mehrere dieser ARM-CPUs bündeln. Das kann auf zweierlei Arten funktionieren. Auf der einen per MB/Backplane, wo man ein lokales Netzwerk hat, an dem dann auch die echten Netzwerkkarten hängen, das wäre dann so was wie ein Cluster-in-a-Box
So sehen doch Cluster mit Infiniband oder was weiß ich schon seit einer gefühlten Ewigkeit aus.
Gipsel
2012-10-30, 13:58:56
Ja klar, aber ein Kabinikern ist ja nicht automatisch ARMv8 kompatibel. Das war so gemeint, dass Kabini sich eventuell recht einfach auf ARMv8 umtrimmen lässt (wg. 64bit, 128bit SIMD und Crypto), plus zusätzlcihem Aufwand / Kleinigkeiten für ARMv7, da man eben kompatibel sein muss und der 64bit Teil vom ARMv8 nicht reicht.Schon klar. Mein Punkt ist vollkommen unabhängig davon ob es sinnvoll ist, einen Jaguar-Kern zum ARM-Kern umzubauen (ziemlich sicher ist es das nicht): Wenn man irgendwas ARMv8 kompatibel gemacht hat, ist ARMv7 schon mit dabei, sonst wäre es kein ARMv8 (denn dazu gehört auch der 32Bit Modus und Thumb). ;)
Anders gefragt: Sollte AMD den ARM-Kern von Grund auf neu entwerfen und kann überhaupt nichts von Kabini wiederverwerten?
Was man verwenden könnte, ist KnowHow. OoOE-Logik, Branch-Prediction, wie man Memory Disambiguation macht, schnelle Cache- bzw. Speicherinterfaces designed, Tricks bei den FPUs. Sowas ist meist unabhängig von der ISA (weil es außer der Branch-Prediction Features des RISC-Kernes hinter den Decodern sind).
Nakai
2012-10-30, 14:49:42
Was man verwenden könnte, ist KnowHow. OoOE-Logik, Branch-Prediction, wie man Memory Disambiguation macht, schnelle Cache- bzw. Speicherinterfaces designed, Tricks bei den FPUs. Sowas ist meist unabhängig von der ISA (weil es außer der Branch-Prediction Features des RISC-Kernes hinter den Decodern sind).
Ich glaube kaum, dass AMD einen ARM-Kern komplett neu entwickelt. Das wäre einfach eine riesige Zeitverschwendung. IMO wird man ein bestehendes ARM-Design als Basis benutzen. Dazu einige Erfahrungen vom X86 und ein dementsprechendes Backend für die CPU-Kommunikation.
AMD wird wohl kaum ein Design von grundauf entwickeln.
SavageX
2012-10-30, 15:04:26
Ich glaube kaum, dass AMD einen ARM-Kern komplett neu entwickelt. Das wäre einfach eine riesige Zeitverschwendung. IMO wird man ein bestehendes ARM-Design als Basis benutzen. Dazu einige Erfahrungen vom X86 und ein dementsprechendes Backend für die CPU-Kommunikation.
AMD wird wohl kaum ein Design von grundauf entwickeln.
Vermutlich werden sie erstmal einen ganz normalen ARM Kern verbauen, kein eigenes Design:
Today's announcement is about a processor license, not an ARM architecture license - in other words, AMD will integrate an ARM designed 64-bit core for this new Opteron.
http://www.anandtech.com/show/6418/amd-will-build-64bit-arm-based-opteron-cpus-for-servers-production-in-2014
Noch ein CPU-Design auf die Beine zu stellen ist vermutlich einfach nicht drin, weder in Bezug auf Geld noch auf Zeit.
Schon klar. Mein Punkt ist vollkommen unabhängig davon ob es sinnvoll ist, einen Jaguar-Kern zum ARM-Kern umzubauen (ziemlich sicher ist es das nicht): Wenn man irgendwas ARMv8 kompatibel gemacht hat, ist ARMv7 schon mit dabei, sonst wäre es kein ARMv8 (denn dazu gehört auch der 32Bit Modus und Thumb). ;)
Stimmt hast recht, ich hätte AArch64 schreiben sollen ^^
Ich glaube kaum, dass AMD einen ARM-Kern komplett neu entwickelt. Das wäre einfach eine riesige Zeitverschwendung. IMO wird man ein bestehendes ARM-Design als Basis benutzen. Dazu einige Erfahrungen vom X86 und ein dementsprechendes Backend für die CPU-Kommunikation.
AMD wird wohl kaum ein Design von grundauf entwickeln. Beim letzten Satz stimme ich absolut zu, aber wieso sie ein 08/15 ARM Design verwenden sollen, wenn sie den aktuell besten x86 Stromsparkern in-house haben erschließt sich mir nicht. Ein Bobcat-Kern war kleiner als ein Atom, verbrauchte nicht viel mehr Leistung, hatte aber die deutlich bessere IPC. Da steckt einiges an know-how drin. Also wenn, dann basieren sie Ihren ARM Kern auf Ihr x86-know-how. Alles andere wäre selten dämlich. Ob man das nun Jaguar-Umbau nennt, oder Jaguar-Komponenten-Reuse ist mir dabei egal ^^
Edit:
Doll alles für umsonst, was ich geschrieben habe, also doch nur ARM Kopien. Wie langweilig. Thx @ SavageX.
Aber der Vorteil liegt auch auf der Hand: Billige Entwicklung.
robbitop
2012-10-30, 15:31:59
In der klammen Situation, in der sich AMD befindet, wird man wohl eher fertige ARM Cores lizensieren.
Shink
2012-10-30, 15:54:39
Das macht doch jeder anfangs und wirklich unvernünftig find ich das nicht. Wenn man mehr Performance als die ARM-Konkurrenz will, kann man ja eine x86-CPU verbauen.
Skysnake
2012-10-30, 20:41:37
jup, da kommt es halt nur auf eins drauf an. Billige stromsparende CPUs mit ner recht guten IO Performance durch die Masse
=Floi=
2012-10-30, 21:12:42
nur wo soll denn da unterm strich für den betreiber der vorteil liegen?
billigste dual sandy cpus gibt es für 35€. Es dürfte auch flexibler und leistungsfähiger sein große cpus mit möglichst viel speicher zu koppeln und nicht zig server mit wenig speicher und rechenleistung.
da müsste soch ein chip für 5€ zu haben sein und ein komplettes board für 20€. jeder m² im serverraum kostet auch geld.
=Floi=
2012-10-30, 21:14:40
wenn sie den aktuell besten x86 Stromsparkern in-house haben erschließt sich mir nicht.
;D :freak:
deshalb ist bulldozer unter last so sparsam.
Ravenhearth
2012-10-30, 21:20:02
;D :freak:
deshalb ist bulldozer unter last so sparsam.
Er meint sicherlich nicht Bulldozer...;)
nur wo soll denn da unterm strich für den betreiber der vorteil liegen?
billigste dual sandy cpus gibt es für 35€. Es dürfte auch flexibler und leistungsfähiger sein große cpus mit möglichst viel speicher zu koppeln und nicht zig server mit wenig speicher und rechenleistung.
Ohne ECC gehts nichts, such mal die billigste 32 oder 22nm Intel CPU mit ECC raus, dann reden wir weiter ;-)
deshalb ist bulldozer unter last so sparsam.
Hmm, dachte das wäre mittlerweile Allgemeinwissen aber gut:
AMD hat 2 Kerne, Bulldozer & Bobcat. Die haben miteinander nichts zu tun. Der Schluss von einem zum anderen ist so sinnvoll wie von Dir zu Angela Merkel.:freak:
Skysnake
2012-10-30, 21:23:02
nur wo soll denn da unterm strich für den betreiber der vorteil liegen?
billigste dual sandy cpus gibt es für 35€. Es dürfte auch flexibler und leistungsfähiger sein große cpus mit möglichst viel speicher zu koppeln und nicht zig server mit wenig speicher und rechenleistung.
da müsste soch ein chip für 5€ zu haben sein und ein komplettes board für 20€. jeder m² im serverraum kostet auch geld.
Wie gesagt IO intensive Anwendungen.
Du weißt doch, das CPUs auf den RAM hunderte Takte warten müssen, und bei der Festplatte, selbst SSD reden wir lieber erst gar nicht drüber.
Es gibt genug Anwendungsbereiche, wo die High-End CPU einfach nur am warten ist. Das bringt dir nichts sondern kostet einfach nur in der Anschaffung und auch im Unterhalt.
Twodee
2012-10-30, 21:25:47
Er meint sicherlich nicht Bulldozer...;)
Er meint natürlich Zacate. Wobei ich aber den Ivy Pentium DualCore für den besten x86 Stromsparkern halte, aber den hat ja AMD nicht :freak:
Er meint natürlich Zacate. Wobei ich aber den Ivy Pentium DualCore für den besten x86 Stromsparkern halte, aber den hat ja AMD nicht :freak: Ich meinte Bobcat und das stand auch gleich im nächsten Satz.
Ivy P Dual ist gut , aber ich sprach von ner Kern-µArchitektur, nicht von nem Herstellungsprozess. In 22nm hätte der Ivy P Dual im Tripeltest aus Stromverbrauch/Die-Size/Leistung keine Chance gegen nen Bobcat im gleichen Prozess. Wenns anders wäre, würde Intel nicht an nem OoO-Atom-Nachfolger werkeln.
Twodee
2012-10-30, 21:41:21
Würde ich nicht unbedingt meinen. Ivy hat mehr Onboard (3MB L3, Dual IMC, PCI-E..), und er ist um einige Faktoren schneller. Aber klar, kann man schwer vergleichen.
Würde ich nicht unbedingt meinen. Ivy hat mehr Onboard (3MB L3, Dual IMC, PCI-E..), und er ist um einige Faktoren schneller. Aber klar, kann man schwer vergleichen.Wie besagt, wenns anders wäre, würde Intel sicherlich keine Millionen in den Atom-Nachfolger investieren, sondern sich einfach nen Ivy zurechtbiegen.
Siehe auch Intels Microserver-CPU:
http://www.xbitlabs.com/news/cpu/display/20121016235425_Intel_s_Next_Gen_Atom_Avoton_Chip_for_Micro_Servers_to_Feature_Ei ght_Cores_New_Memory_Controller_Media.html
Das ist kein Ivy.
Undertaker
2012-10-30, 23:33:53
Ivy/Haswell/... ist (auch im Server) einfach völlig anders ausgerichtet als ein entsprechendes Atom-Modell. Letzteres dürfte fast ausschließlich auf brauchbare Leistung bei hohen Threadzahlen zielen.
Übrigens: Was die Performance pro Watt des CPU-Teils betrifft, liegt der 32nm Atom je nach Modell wohl etwa auf einem Level mit Ivy Bridge (N2650: 2x 1,73 GHz bei 3,6 Watt!). Bobcat hat es da selbst in Form des Tablet-Modells Z-60 (2x 1,0 GHz bei 4,5 Watt) ziemlich schwer, selbst wenn man die schnellere IGP einbezieht. Fairerweise muss man allerdings auf den Fertigungsnachteil hinweisen.
Du hast jetzt aber nicht wirklich die TDP zum Vergleich genommen? Ich kann dir garantieren, dass Bobcat die weitaus effizientere Architektur als Bonnell ist.
Undertaker
2012-10-31, 10:50:33
Bobcat ist kleiner und hat zudem, wie erwähnt, die zweifellos überlegene GPU, bzgl. Leistung/Watt (CPU-only, Multithread) sehe ich Atom aber vorn. Wenn ich nach dem idle-load-Delta gehe, verbraucht selbst ein 45nm D525 nur einen Bruchteil (http://www.computerbase.de/artikel/prozessoren/2011/test-amd-brazos/18/) eines E350.
Edit: Cedar Trail: http://www.xbitlabs.com/articles/cpu/display/atom-cedartrtail_9.html#sect0
Mit der Effizienz des CPU-Teils kann Bobcat nicht einmal annähernd konkurrieren.
robbitop
2012-10-31, 12:02:37
Dein Link zeigt doch zumindest beim 45 nm Atom das Gegenteil. Idle und Prime95 liegt Brazos vorn. Dass Intel heute mit 32 nm einen Fertigungsvorteil hat, ist klar. Kabini zieht dann erst gleich.
Das ist halt ein permanenter Vorteil, den Intel immer hat. Die sind meist einen Full-Node vorn.
Undertaker
2012-10-31, 12:37:37
Die Gesamtwerte sind logischerweise stark vom Systemumfeld beeinflusst, wo beim Atom gerade in der Vergangenheit gerne mal "geschlampt" wurde. Für die Einschätzung des Verbrauches relevant ist aber die Differenz zwischen Leerlauf und CPU-Volllast. Da verbraucht selbst ein 45nm Atom wirklich extrem wenig - selbst in Anbetracht der schmächtigen Rechenleistung.
Ob das aktuelle ARM-Chips viel besser können? In Form des Z2460 schlägt sich Atom ja auch in Smartphones nicht schlecht.
Skysnake
2012-10-31, 13:00:52
Dein Link zeigt doch zumindest beim 45 nm Atom das Gegenteil. Idle und Prime95 liegt Brazos vorn. Dass Intel heute mit 32 nm einen Fertigungsvorteil hat, ist klar. Kabini zieht dann erst gleich.
Das ist halt ein permanenter Vorteil, den Intel immer hat. Die sind meist einen Full-Node vorn.
Wobei Sie diesen Vorteil in den nächsten Jahren sich sehr teuer erkaufen werden, und bis ca. 2020 hat sichs dann auch mit derm Vorteil, da wir einfach an die Grenzen der Technik kommen. Wenn muss dann was ganz neues kommen, und da wird es sich wohl selbst Intel schwer überlegen müssen, ob Sie da alleine voran gehen oder nicht.
Die Gesamtwerte sind logischerweise stark vom Systemumfeld beeinflusst, wo beim Atom gerade in der Vergangenheit gerne mal "geschlampt" wurde. Für die Einschätzung des Verbrauches relevant ist aber die Differenz zwischen Leerlauf und CPU-Volllast. Da verbraucht selbst ein 45nm Atom wirklich extrem wenig - selbst in Anbetracht der schmächtigen Rechenleistung.
Ob das aktuelle ARM-Chips viel besser können? In Form des Z2460 schlägt sich Atom ja auch in Smartphones nicht schlecht.
Deine Logik hat einen gewaltigen Hacken...
Nimm die gleiche CPU und verbesser die Stromsparmechanismen für den Idle.
Was passiert jetzt?
Richtig. Die neue CPU mit den besseren Stromsparmechanismen steht jetzt schlechter da als die alte :freak:
Ich hoffe du erkennst das Problem von reinen Delta-Betrachtungen zwichen Idle und Load.
y33H@
2012-10-31, 13:09:26
Haken bitte *schüttel* im Smartphone-Bereich steht der Atom ziemlich gut da übrigens (Akkulaufzeit des Razr i im Vergleich zum HD, wobei das halt das größere Display hat).
Dural
2012-10-31, 13:14:43
er sagte ja das drum herum verbraucht mehr, die CPU für sich benötigt sicher weniger als eben der AMD. das wird sicher so sein und zeigt sich ja eben gerade beim Delta sehr deutlich.
es sei den der Idle verbrauch des Atom Core ist wirklich so schlecht, aber da würde ich sagen dass das Intel eigentlich im griff haben sollte.
Undertaker
2012-10-31, 13:22:45
Deine Logik hat einen gewaltigen Hacken...
Nimm die gleiche CPU und verbesser die Stromsparmechanismen für den Idle.
Was passiert jetzt?
Richtig. Die neue CPU mit den besseren Stromsparmechanismen steht jetzt schlechter da als die alte :freak:
Ich hoffe du erkennst das Problem von reinen Delta-Betrachtungen zwichen Idle und Load.
Da sowohl Atom als auch Bobcat im Milliwatt-Bereich idlen, ein theoretisch berechtigter, praktisch aber nicht relevanter Einwand.
Skysnake
2012-10-31, 13:44:24
Bei einem Watt Delta-Unterschied sind hundert Milliwat schon nicht mehr vernachlässigbar.
Keine Ahnung, wie hoch die Idle-Verbräuche sind, aber so einfach ist das nicht.
Vor allem muss man erstmal richtig messe, und daran scheiterts ja schon meist, denn das kannst du zuverlässig nur mit nem preparierten Sockel, und ich weiß wirklich nicht, wer das wirklich macht.
Wir reden hier ja nur über einige wenige Watt, und nicht 20W+ an Unterschied, wo man dann die Randbedingungen vernachlässigen kann.
Undertaker
2012-10-31, 14:08:41
Also für mich sind das recht saubere Relationen. In obigem CB-Test haben wir z.B. 3 E-350 Boards, die im Leerlauf zwischen 21 und 27 W, unter Last 32 bis 37 W verbrauchen. Das Delta ist mit 10 bis 11 Watt extrem konstant. Bei XBit sind es ohne PSU 9,4 Watt, eine weitere Bestätigung.
Der Atom liegt bei CB bei einem Delta von 2 Watt, was durch die fehlende Nachkommastelle aber recht ungenau sein kann. XBit hat für den D525 3,9 Watt, für die 32nm-Modelle 2,2 bis 2,4 Watt. Das sollte ausreichend belegen, dass der Atom bei CPU-Last sparsamer und effizienter ist - auch als 45nm-Modell. Durch die größere Chipfläche sollte man das natürlich nicht überbewerten.
Skysnake
2012-10-31, 14:14:54
Und wo misst man?
An den Mainboard-Steckern?
Wenn ich nen 100W Verbrauch hab, dann schwamm ich da drüber,
aber dochnicht, wenn ich von von <5 W rede :ugly:
Ich finde da nur Messungen direkt am Sockel für Aussagefähig. Man muss ja bedenken, das man ja mit nem Fehler, der so groß ist wie die Differenz absolut nichts anfangen kann.
Undertaker
2012-10-31, 14:18:48
Wenn du dich da auf XBit beziehst (CB misst wohl das Gesamtsystem): Woher soll da plötzlich ein Fehler kommen, der nur Bobcat betrifft? Wenn das Delta dort fast 4x so groß wie bei den 32nm Atoms ist, ist das doch mehr als eindeutig.
(del676)
2012-10-31, 14:19:29
Coole Sache, aber nicht wirklich ueberraschend.
zig mobile devices -> arm
zig nas/router systeme -> arm
raspberry -> arm (grad mal 3,5-5 watt und kannst ohne probs hd video schaun)
Und was haben sie alle gemein? Super Linux Unterstuetzung.
Was wird am Servermarkt am oeftesten eingesetzt? Genau. ;)
1+1=2
Wenn das jetzt auch noch fuer Homeuser kommt, waers super. Konkurrenz ist immer gut.
grad mal 3,5-5 watt und kannst ohne probs hd video schaun
Hat genau null mit ARM zu tun.
Was wird am Servermarkt am oeftesten eingesetzt?
x86-64. Mit Abstand.
AnarchX
2012-10-31, 15:38:59
Ging wohl eher um Linux als Server-OS.
Aber da der Markt nach ARM-Micro-Servern verlangt, ist es aus AMDs Position als etablierter Anbieter im Server-Markt in der Tat keine schlechte Idee entsprechende CPUs anzubieten.
Aber im Endkunden-Bereich wird man wohl erstmal weiter auf x86 setzen, da man hier entsprechend investiert hat.
Skysnake
2012-10-31, 16:23:40
oder man machts wie aktuell und bringt beides in einem DIE und lässt den Kunden entscheiden ;)
Undertaker
2012-10-31, 16:31:09
Weil es sich gerade anbietet:
http://www.anandtech.com/show/6422/samsung-chromebook-xe303-review-testing-arms-cortex-a15/6
CPU-seitig steht so ein Cortex-A15 schon ziemlich nett da. Das idle-load-Delta ist allerdings trotz 28nm-Fertigung nicht unerheblich.
Wo siehst du da einen vergleichbaren CPU-Test?
Das Browser-Zeug hängt viel zu sehr vom Javascript-JITC ab.
Undertaker
2012-10-31, 16:35:40
Keine Vergleichbarkeit trotz identischem Chrome-OS/Browser? Dann setze ich meine Performance-Aussage mal besser in Klammern.
PatkIllA
2012-10-31, 16:37:20
Wo siehst du da einen vergleichbaren CPU-Test?
Das Browser-Zeug hängt viel zu sehr vom Javascript-JITC ab.
In wie weit gehen die JITC da eigentlich auf die Unterschiede innerhalb der Architektur ein? Ein Atom würde doch wahrscheinlich einen anderen Code bevorzugen als ein Bulldozer.
Sind die nicht sowohl auf x86 als auch auf ARM mittlerweile ziemlich durchoptimiert?
Keine Vergleichbarkeit trotz identischem Chrome-OS/Browser? Dann setze ich meine Performance-Aussage mal besser in Klammern.Vergleiche den IE in 32 und 64 Bit. Der 64 Bit ist ihn einigen Dingen deutlich langsamer. Ist das beim IE10 immer noch so?
Gipsel
2012-10-31, 16:39:23
Weil es sich gerade anbietet:
http://www.anandtech.com/show/6422/samsung-chromebook-xe303-review-testing-arms-cortex-a15/6
CPU-seitig steht so ein Cortex-A15 schon ziemlich nett da.
Die dort abgebildete Pipelinekonfiguration des A15 kann übrigens gar nicht stimmen. Beide Integer ALUs an einem Issue-Port? Selten was Bescheuerteres gesehen.
Edit:
Das sagt ARM selber (die Anzahl der Kästchen ist übrigens die Pipeline-Länge, die weißen mit "Queue" beschrifteten können übersprungen werden):
http://eda360insider.files.wordpress.com/2012/01/arm-cortex-a7-and-cortex-a15-pipelines.jpg
Gibt also 8 Issue-Ports (A7 hat 5 execution units, die von einem einzelnen dual issue Port versorgt werden [ist ja in-order]). Cortex A57 und A53 sehen übrigens laut der ARM-Präsentation von der Pipeline identisch aus. Die Performancesteigerung kommt also aus Änderungen im Detail. Krait hat ja angeblich 9 Ports, die aber offenbar nicht ganz so gut genutzt werden, der A9 steht bei 3+1 Ports (2 x Integer-ALU, 1x AGU/L/S + optional 1 Port für Neon/VFPv3). Gefüttert wird Alles unter Krait/A15 von zwei Decodern (okay nicht Alles, die alten Designs natürlich nicht), Krait und A15 haben drei.
Keine Vergleichbarkeit trotz identischem Chrome-OS/Browser? Dann setze ich meine Performance-Aussage mal besser in Klammern.
Es ist mit großer Vorsicht zu genießen.
Ailuros
2012-10-31, 20:26:26
Es ist mit großer Vorsicht zu genießen.
Ich bin trotz allem immer noch nicht ueberzeugt dass der dual A15 im Exynos5250 langsamer ist als ein fast gleich getakteter Atom im N570. Die Frage waere ob der Endverbraucher in einem Chromebook mit Exynos5 und einem um 45% niedrigeren MSRP wirklich insgesamt im Nachteil steht im Vergleich zum vorigen Atom Chromebook. ARM's CPU engineers haben zwar direktes Interesse hartnaeckig zu bestehen dass es nicht der Fall ist und ich bin auch gutmuetig genug ihnen zu glauben, aber meine Hand dafuer ins Feuer lege ich nicht.
Auf jeden Fall ist erstmal die GMA3150 der T604 GPU gnadenlos unterlegen. Der Grund warum Intel's integrierte GPUs bis jetzt unnoetig viel die area schlucken haben wir ja schon besprochen.
Was die CPUs aber betrifft will ich mehr Daten sehen um darueber ueberzeugt zu werden. Von dem was ich bis jetzt lese sieht es nicht danach aus dass die neuen Cortex A5x CPUs hoeher takten werden als die A15 (ausser die meisten haben etwas verpasst was ich auch selber nirgends sehen konnte).
(del676)
2012-10-31, 20:37:17
Hat genau null mit ARM zu tun.
Whine woanders, oder zeig mir einen x86 ders schafft. ;)
x86-64. Mit Abstand.
Falsche Antwort.
LINUX!
Deshalb auch 1+1=2 ;)
Twodee
2012-10-31, 21:09:52
Whine woanders, oder zeig mir einen x86 ders schafft. ;)
Mein A8 3870K lief letztens nach dem XBMC Update ohne GPU-Beschleunigung.
Die CPU lief zwar auf Anschlag, aber HD (Bluray-Rip) war ruckelfrei möglich.
(del676)
2012-10-31, 21:31:56
und das bei 4-5 Watt gesamte Leistungsaufnahme?
Whine woanders, oder zeig mir einen x86 ders schafft. ;)
Jeder Atom, jeder Bobcat?
Dir ist schon klar, dass da die CPU exakt nichts macht? Das ist ein eigener Hardware-Stein drauf für's H.264-Decoding.
Twodee
2012-10-31, 21:59:54
und das bei 4-5 Watt gesamte Leistungsaufnahme? :rolleyes:
klar,
mit einer entsprechenden iGPU, ja
(del676)
2012-10-31, 22:16:05
Jeder Atom, jeder Bobcat?
Dir ist schon klar, dass da die CPU exakt nichts macht? Das ist ein eigener Hardware-Stein drauf für's H.264-Decoding.
Das war nur ein Beispiel. Dann nehmen wir halt was andres her. Apache Webserver, FTP Server, Teamspeak Server, Samba Server, was weiss ich was alles. Wenn ich mir die Atom Foren ansehen, duempeln die bei 10-12 Watt rum (idle!)
Ausserdem hab ich noch keine Server gesehen die z.b. mit 512 Atom Cores kommen? Oder ist da was in der Pipeline?
Ausserdem performt ein A9 ziemlich gut. http://www.androidauthority.com/cortex-a9-beats-intel-atom-same-clock-speed-112227/
][immy
2012-11-01, 00:28:47
Das war nur ein Beispiel. Dann nehmen wir halt was andres her. Apache Webserver, FTP Server, Teamspeak Server, Samba Server, was weiss ich was alles. Wenn ich mir die Atom Foren ansehen, duempeln die bei 10-12 Watt rum (idle!)
Ausserdem hab ich noch keine Server gesehen die z.b. mit 512 Atom Cores kommen? Oder ist da was in der Pipeline?
Ausserdem performt ein A9 ziemlich gut. http://www.androidauthority.com/cortex-a9-beats-intel-atom-same-clock-speed-112227/
der Test hinkt aber ein wenig. die schicken einen Atom Prozessor auf ein Linux (vermutlich allgemein x86er optimiert) und den ARM Prozessor auf ein für ARM optimiertes Linux.
Der Atom Prozessor ist zwar bei weitem nicht gerade eine Rakete (z.B. mal mit Bobcat vergleichen) aber von der generellen Performance her sollte er den ARM locker übertreffen. außer eventuell in Spezialgebieten wo der A9 vielleicht die eine oder andere Spezialeinheit mit an Bord hat. Aber genau das ist es ja eigentlich was ARM hier so interessant macht. Hochspezialisierte Server mit wenig Stromverbrauch könnte man damit erstellen. Aber sobald man allgemeine Rechenkraft bräuchte ist ARM ein wenig arm dran.
Das wird sich mit A15 und vor allem dem ARMv8-Zeug aber schnell ändern jetzt.
Ailuros
2012-11-01, 01:03:39
Atom gegen A9 vielleicht schon, aber ich hab immer noch meine Zweifel dass die Analogie immer noch so ist zwischen Atom und A15.
Im Clovertrail taktete die CPU bis vor kurzem bis zu 1.8GHz gegen die erste A15 Implementierung im Exynos5250 bei 1.7GHz. Wenn Intel wirklich in einer so angenehmen Leistungs-"safe zone" liegen wuerde frage ich mich ernsthaft warum Intel vor kurzem ohne jegliche Fanfare mal schnell eine zusaetzliche SoC Variante mit hoeherer CPU Frequenz dazugesteckt hat.
***edit: http://www.fudzilla.com/home/item/29271-intel-silently-slip-in-atom-d2560-cpu
Gipsel
2012-11-01, 01:08:58
Ausserdem hab ich noch keine Server gesehen die z.b. mit 512 Atom Cores kommen? Oder ist da was in der Pipeline?Na klar gibt es die, unter anderem sogar von AMD (http://www.seamicro.com/node/251) (hat genau Deine geforderten 512 Atom Cores, gibt auch noch eine Version mit 768). ;D
robbitop
2012-11-01, 08:36:50
Für mich ist es keine Überraschung, dass eine OoO CPU mit 3-issue eine IO CPU mit 2-issue bei ähnlichem Takt besiegt. Und ja: ich weiß, dass das sehr oberflächlich ist und nichts aussagt. Aber es ist immerhin ein guter Indikator. :)
Wenn die Daten aus den Benchmarks stimmen, könnte A15 soziemlich auf Bobcat Niveau liegen. Wahnsinn, wie schnell sich die ARMs entwickelt haben.
Ronny145
2012-11-01, 10:34:05
Wenn Intel wirklich in einer so angenehmen Leistungs-"safe zone" liegen wuerde frage ich mich ernsthaft warum Intel vor kurzem ohne jegliche Fanfare mal schnell eine zusaetzliche SoC Variante mit hoeherer CPU Frequenz dazugesteckt hat.
***edit: http://www.fudzilla.com/home/item/29271-intel-silently-slip-in-atom-d2560-cpu
Könntest Du mir verraten, wo die Besonderheit in dem leichten CPU upgrade steckt? 100-200 Mhz Taktsteigerungen 1 Jahr nach release sind bei Intel normales Tagesgeschäft und findest du durch die Bank weg im Core Geschäft. Im übrigen gab es eine noch schnellere Variante mit dem D2700.
Ailuros
2012-11-01, 19:04:15
Könntest Du mir verraten, wo die Besonderheit in dem leichten CPU upgrade steckt? 100-200 Mhz Taktsteigerungen 1 Jahr nach release sind bei Intel normales Tagesgeschäft und findest du durch die Bank weg im Core Geschäft. Im übrigen gab es eine noch schnellere Variante mit dem D2700.
Ueberhaupt keine Besonderheit; aber dass es ueberhaupt nichts mit jeglicher konkurrierenden Loesung zu tun hat in solchen Faellen muss mir wohl jemand erstmal beweisen, eben weil selbst Intel nicht in einem Vakuum operiert.
***edit: D2560 steht fuer Cedar und nicht Clovertrail...wenn ich es je schaffe die Codenamen bei Intel nicht uneindande zu bringen *seufz*
sloth9
2013-06-19, 15:06:26
Wohl nach aktueller Roadmap (http://www.3dcenter.org/news/amd-bringt-2014-arm-sowie-kaveri-basierte-server-prozessoren) nur 08/15-Cortex-A57-CPUs. Boring as Hell!
Knuddelbearli
2013-06-19, 16:17:58
naja wenn sie Jaguar beerben sollen muss ja auch eine IGP dabei sein, und damit auch huma / Fusion fähig
Beerben? AMD wird doch wohl nicht die Jaguar-Architektur komplett durch ARM ersetzen wollen?
dildo4u
2013-06-19, 16:32:52
AMD says that the ARM SoCs will offer two to four times the performance of the just-announced x86-based low-power Opteron CPUs, though this performance figure would appear to come from the boosted core count (eight or 16 compared to four). Given that they have similar clock speeds, then, it would appear that AMD is expecting the Cortex-A57 architecture to perform as well as its "Jaguar" CPU architecture while using less power overall.
http://arstechnica.com/information-technology/2013/06/amd-announces-its-first-64-bit-8-and-16-core-arm-based-server-socs/
Vermutlich sind die Cores deutlich kleiner und man kann so 16 unterbringen statt den jetzigen 4.
Skysnake
2013-06-19, 16:35:25
Beerben? AMD wird doch wohl nicht die Jaguar-Architektur komplett durch ARM ersetzen wollen?
aktuell muss man wohl davon ausgehen, wobei ich das auch nicht verstehe, und auch für gefährlich halte.
Die beiden Produkte ergänzen sich eigentlich ziemlich gut.
http://arstechnica.com/information-technology/2013/06/amd-announces-its-first-64-bit-8-and-16-core-arm-based-server-socs/
Vermutlich sind die Cores deutlich kleiner und man kann so 16 unterbringen statt den jetzigen 4.
Nö, sind sie nicht.
dildo4u
2013-06-19, 16:53:37
Was noch sein könnte sie sind nich dafür gebaut über 4 Core's hinaus erweitert zu werden,es wäre also im Prinzip sowas wie die ersten Intel Quad's.(Getrennte Caches zwischen Cores 1-4 und 5-8)
SavageX
2013-06-19, 16:57:26
Beerben? AMD wird doch wohl nicht die Jaguar-Architektur komplett durch ARM ersetzen wollen?
Nun, hier geht es ja um Server. Derzeit hält für Microserver der gerade eingeführte Jaguar die Stellung, praktisch als Nebenprodukt der mobilen APUs. Allerdings kommt ja Intel demnächst mit doppelt so vielen Kernen um die Ecke, also muss AMD nachlegen. Jetzt könnten sie vermutlich schon einen 8-Kern Jaguar mit dem SeaMicro-Fabric zusammenbauen, der aber im Markt für mobile x86 APUs schlecht zu positionieren ist, was die Investitionen schwieriger wieder reinholbar macht (der Markt für Microserver ist ja immer noch vergleichsweise klein). Da man sich ja sowieso in der ARM-Welt positionieren will, versucht man es also "risikominimiert" mit normalen ARM Kernen und einem Server-Drumherum.
Im Markt für APUs gehe ich mal davon aus, dass Jaguar fortbestehen wird.
AnarchX
2013-06-19, 17:14:18
Das zeigt auch diese Roadmap:
http://semiaccurate.com/assets/uploads/2013/06/AMD-Server-Roadmap.png
http://semiaccurate.com/2013/06/17/amd-announces-seattle-berlin-and-warsaw-for-servers/amd-server-roadmap/
APU wird von Berlin übernommen und 16 ARM-Cores sind wohl ein besserer Gegner gegen Intels Avoton.
Skysnake
2013-06-19, 19:12:18
Wahrscheinlich.
Btw.
Gibt es eigentlich einen Link zu der Aussage, das es "nur" stink normale A57 ARM Cores werden sollen, ohne jedweden Customteil?
Gibt es eigentlich einen Link zu der Aussage, das es "nur" stink normale A57 ARM Cores werden sollen, ohne jedweden Customteil?Steht doch auf der Roadmap unter "Seattle" rechts unten im Eck.
Oder meinst Du nen "custom A57" ? Das wär dann kein A57 mehr. A57 ist A57 so wie ein Jaguar-Core ein Jagar-Core ist.
Custom wird nur der Rest auf dem SoC, da will AMD halt mit ihren Seamicrolink punkten.
mczak
2013-06-19, 19:17:55
Sind die A57 eigentlich in irgend einer Hinsicht besser als Jaguar (also perf/w, perf/die size oder sowas). Die Aussage 2 bis 4x mal schneller als bei Kabini bei 2 bis 4 mal mehr Kernen deutet jedenfalls darauf hin dass die Performance pro Kern so gut wie identisch ist (was auch nicht unerwartet wäre). Und nach allem was man hört über den Stromverbrauch von A15 habe ich jedenfalls meine Zweifel dass da A57 weit vorne liegt (auch wenn wohl A57 eine Verbesserung gegenüber A15 sein wird bezüglich perf/w).
Würde man 16-Kern Jaguar bauen hätte man wenigstens bloss einen Konkurrenten, mit ARM Chips weiss man das nicht so genau :-). Da muss AMD darauf vertrauen dass die Fabric wirklich den Vorteil ausmacht.
Skysnake
2013-06-19, 19:25:24
Steht doch auf der Roadmap unter "Seattle" rechts unten im Eck.
Oder meinst Du nen "custom A57" ? Das wär dann kein A57 mehr. A57 ist A57 so wie ein Jaguar-Core ein Jagar-Core ist.
Custom wird nur der Rest auf dem SoC, da will AMD halt mit ihren Seamicrolink punkten.
Nicht zwingend.
Man kann ja sowhl den kompletten IP-Block nehmen ,oder einfach nur den Instructionsumfang eines A57, aber im Detail dann doch nochmals gewisse Anpassungen vornehmen.
Hier bischen Sprungvorhersage, da bischen Hardware Dividierer usw.
Nicht zwingend.
Man kann ja sowhl den kompletten IP-Block nehmen ,oder einfach nur den Instructionsumfang eines A57, aber im Detail dann doch nochmals gewisse Anpassungen vornehmen.
Instruktionsumfang?
Du meinst ne Architekture-Lizenz? Dann stünde da ARMv8 nicht Cortex A57. Das ist wie besagt eindeutig, das ist ein fertiger Kern aus einem Guss, da gibts nichts zu rütteln.
mczak
2013-06-19, 20:27:49
Man kann ja sowhl den kompletten IP-Block nehmen ,oder einfach nur den Instructionsumfang eines A57, aber im Detail dann doch nochmals gewisse Anpassungen vornehmen.
Nimmst du bloss den Befehlsumfang eines A57 ist das einfach armv8, genau dasselbe wie ein A53.
Wobei es gab schon auch leicht getunte Kerne ohne gleich komplett auf Eigenbau zu setzen, der Samsung Hummingbird war doch ein getunter Cortex-A8 auch der Qualcomm Scorpion war am Ende doch gar nicht so verschieden.
Scheint aber etwas aus der Mode zu kommen die Custom-Designs scheinen sich heute stärker zu unterscheiden - also entweder ein fixfertiger Kern oder aber dann mehr oder weniger kompletter Eigenbau. Hängt vielleicht damit zusammen sobald du da anfängst am Design zu schrauben musst du natürlich das ganze Design auch selber validieren etc. so dass sich das vielleicht einfach nicht lohnt. Denn wären die Tweaks so simpel und offensichtlich nützlich hätte die arm wohl ja schon selbst vorgenommen. Wie's mit dem Zeitfaktor aussieht weiss ich auch nicht, denn wenn du ein Design frisieren willst brauchst du natürlich erst mal das fertige Design, ein eigenes Design kann natürlich auch schon vorher begonnen werden.
robbitop
2013-06-20, 10:46:17
Wohl nach aktueller Roadmap (http://www.3dcenter.org/news/amd-bringt-2014-arm-sowie-kaveri-basierte-server-prozessoren) nur 08/15-Cortex-A57-CPUs. Boring as Hell!
Es ist ein Custom SoC mit ARM A57 Cores. Die Dinger sind von der IPC und von der Perf/W relativ gut.
Ich vermute weniger IPC als Jaguar aber bessere Perf/W.
Um einen eigenen ARM Core zu entwickeln, bräuchte es wohl mehr Zeit und vieleicht auch Know How zu ARM Cores. Ich weiß nicht, ob man das derzeit in-house hat. Ansonsten für einen ersten Schritt erstmal sehr gut. AMD hat im Moment nicht all zu viel Ressourcen und der A57 wird eine gute Basis dafür sein. Vieleicht entwickelt man ja mittel/langfristig eigene ARM Cores.
Allerdings muss man dann auch immer die Frage stellen, wo da der Vorteil ist. Die Cores, die man direkt bei ARM lizensieren kann, sind idR ziemlich gut. Die Custom Designs müssten wirklich deutlich besser sein, damit sich das auch lohnt. Man darf nicht vergessen, dass der µ-Servermarkt noch eine Nische ist - also keine allzu hohen Stückzahlen. Dafür lohnt sich kurzfristig vieleicht kein eigener Kern.
Ich frage mich allerdings, warum man mit den ARM Opterons die Cat (x86) Cores beerbt? Ich würde die parallel laufen lassen. Die Cats braucht man ja eh. Warum nicht auch einen Opteron dafür auflegen. Für Singlethread dürften die ja weiterhin besser sein...
disap.ed
2013-06-20, 11:23:23
Ich frage mich allerdings, warum man mit den ARM Opterons die Cat (x86) Cores beerbt? Ich würde die parallel laufen lassen. Die Cats braucht man ja eh. Warum nicht auch einen Opteron dafür auflegen. Für Singlethread dürften die ja weiterhin besser sein...
Das ist halt die Frage ob man die wirklich braucht. Auf dem Smartphone/Tablet-Markt tut sich x86 schwer mit der Durchsetzung und im Ultrabook-Markt kann man mit Kaveris antreten. Werden sich schon was gedacht haben dabei.
Knuddelbearli
2013-06-20, 12:44:39
nur war das eine servermap! mit dann 8-16 ARM Core nix Smartphone oder Ultrabook ^^
robbitop
2013-06-20, 15:21:23
Das ist halt die Frage ob man die wirklich braucht. Auf dem Smartphone/Tablet-Markt tut sich x86 schwer mit der Durchsetzung und im Ultrabook-Markt kann man mit Kaveris antreten. Werden sich schon was gedacht haben dabei.
Wozu entwickelt man denn dann die Cats?
Für ein Ultrabook wäre ein Cat zu lahm und ein Bagger zu warm.
Die Cats sind eigentlich eine Gattung von CPUs, die mit dem Aussterben der Netbooks in die Bedeutungslosigkeit rutscht.
Für Tablets muss man sie zu sehr heruntertakten. An Phones ist gar nicht zu denken. Die TDP Klasse bei den Cats passt irgendwie zu keinem, der heute boomenden Märkten...
Hugo78
2014-01-28, 21:31:35
Interessante Aus/Ansage und Aussicht mit Anspruch:
"(by 2019) AMD will be the leader in ARM CPUs,..."
http://www.planet3dnow.de/cms/7741-amd-2019-dominieren-kleine-sparsame-x86-kerne-das-ende-von-bulldozer/
Simon
2014-01-28, 21:53:54
2019 :freak:
Godmode
2014-01-28, 22:14:15
2019 :freak:
Meinst das man 25% Marktanteil von heute auf morgen erreicht, oder was?
Simon
2014-01-28, 22:59:43
Meinst das man 25% Marktanteil von heute auf morgen erreicht, oder was?
Wieso 25%?
Ich meinte, dass 2019 noch 5 Jahre weg ist und AMD erstmal zusehen soll, ueberhaupt dahinzukommen. Schau dir einfach die aktuellen Marktanteile und die Prognosen von vor ein paar Jahren an.
Zumal auf dem Slide steht, dass 2019 25% der Server vielleicht ARM-CPUs haben. Und von den 25% will AMD dann der Leader sein. Wenn man Leader definiert als "Mehr Market Share als jeder Konkurrent", dann reichen dafuer auch 25% von 25% (TI, Qualcomm, Nvidia, Intel, Broadcom, Mediatek, ...) vom Server Markt. Und selbst bei > 50% Market Share der ARM CPUs sind das dann >= 12.5 % des Server Markts. 12.5% Market Share (bei Servern, nicht Desktop PCs) klingt jetzt weder spannend noch beeindruckend.
fondness
2014-01-29, 09:24:35
Ganz schön viel Cache der kleine Chip:
Ab März wird AMD entsprechende Entwicklerkits ausliefern, die mit einem Opteron A1100 bestückt sind. Dahinter verbirgt sich der in 28 nm gefertigte ARM-Prozessor mit vier bis acht Kernen sowie bis zu 4 MByte L2-Cache und 8 MByte L3-Cache, erstmals in 64-Bit-Architektur auf Basis von ARMs Cortex-A57, den AMD für vielfältige Aufgaben in Zukunft sieht.
http://www.computerbase.de/news/2014-01/amds-64-bit-arm-server-prozessor-ab-maerz-als-sample/
http://imagizer.imageshack.us/v2/xq90/18/n2bc.png (https://imageshack.com/i/0in2bcp)
http://imagizer.imageshack.us/v2/xq90/89/r8ph.png (https://imageshack.com/i/2hr8php)
http://imagizer.imageshack.us/v2/xq90/202/0dmq.png (https://imageshack.com/i/5m0dmqp)
http://imagizer.imageshack.us/v2/xq90/11/4h95.png (https://imageshack.com/i/0b4h95p)
http://imagizer.imageshack.us/v2/xq90/21/ipfp.png (https://imageshack.com/i/0lipfpp)
http://imagizer.imageshack.us/v2/xq90/836/xho6.png (https://imageshack.com/i/n8xho6p)
http://imagizer.imageshack.us/v2/xq90/191/4j4a.jpg (https://imageshack.com/i/5b4j4aj)
y33H@
2014-01-29, 10:31:25
PDF: http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9MjE4MjY2fENoaWxkSUQ9LTF8VHlwZT0z&t=1
Schaffe89
2014-01-29, 12:10:28
Der beste Schritt den AMD überhaupt gehen kann. Weg von Intel, weg von x86 only.
Botcruscher
2014-01-29, 12:33:36
Noch eine Verzweiflungstat weil man mit Intel nicht mithalten kann. Den Markt der Kleinserver gibt es schon lange. Da hat AMD aber nichts zu melden. ARM alleine macht nichts besser als x86.
robbitop
2014-01-29, 12:36:21
Der beste Schritt den AMD überhaupt gehen kann. Weg von Intel, weg von x86 only.
Und hinein in's Haifischbecken in den hartumkämpften ARM Markt mit Dumpingpreisen... ;)
Guter Deal! :eek:
Noch eine Verzweiflungstat weil man mit Intel nicht mithalten kann. Den Markt der Kleinserver gibt es schon lange. Da hat AMD aber nichts zu melden. ARM alleine macht nichts besser als x86.
Die Frage ist, wie groß und lohnenswert dieser Markt überhaupt ist. IMO braucht man im ARM Markt Custom Cores, um sich von anderen abzusetzen.
fondness
2014-01-29, 12:50:09
Es kommt ja nicht nur auf den Core an. AMD hat die Infrastruktur (Freedom-Factory) und als einziges Lizenznehmer Erfahrungen und das know-how im Servermarkt. Man wird auch den ersten ernstzunehmenden ARM-Server-SoC bringen. Die ISA alleine bringt natürlich nichts, aber laut AMD ist das Ding zumindest erheblich energieffizienter als die eigenen x86 Jaguar-Kerne.
Botcruscher
2014-01-29, 12:58:48
Die ISA alleine bringt natürlich nichts, aber laut AMD ist das Ding zumindest erheblich energieffizienter als die eigenen x86 Jaguar-Kerne.
Wenn man da an den Stellschrauben dreht bezweifle ich das mal.
Heise:
"Zum Vergleich: Für den 20-Watt-Atom C2750 mit ebenfalls acht Kernen
nennt Intel leider noch keine SPEC-CPU2006-Werte, aber der
17-Watt-Xeon E3-1220L v2 mit nur zwei x64-Kernen kommt im
SPEC_int_rate auf etwa 87 Punkte."
Der Ivy ist nun echt nicht das Sparwunder. In 14nm und mit 4 Kernen wird man da Kreise drum drehen. Wenn man denn will. PS: Dazu der C2750 (http://www.servethehome.com/Server-detail/intel-atom-c2750-8-core-avoton-rangeley-benchmarks-fast-power/)
Und hinein in's Haifischbecken in den hartumkämpften ARM Markt mit Dumpingpreisen... ;)
Guter Deal! :eek:
Seh ich wie fondness, die Fabric wirds richten, die ist wirklich gut und spart $$$.
Die Frage ist, wie groß und lohnenswert dieser Markt überhaupt ist. IMO braucht man im ARM Markt Custom Cores, um sich von anderen abzusetzen.Sind doch auch in Arbeit ... ;-)
Knuddelbearli
2014-01-29, 15:25:41
Der beste Schritt den AMD überhaupt gehen kann. Weg von Intel, weg von x86 only.
und Hin zu anderen Konkurrenten die kaum kleiner sind als Intel, dafür kein Problem mit niedrigen Marktpreisen haben ...
Schritt ist zwar zu begrüßen aber die Argumentation dafür nicht ^^
robbitop
2014-01-30, 10:04:27
Eben. Zumal der Mikroserverbereich IMO noch überschätzt wird. Calxeda hat sich für diese Sparte stark eingesetzt und hat innovative ARM Prozessoren entwickelt. Am Ende haben sie nur Geld verbrannt und sind heute insolvent.
Die besten Margen verdient man noch immer im normalen Server/Enterprisebereich und im Notebook (insbesondere bei Ultrabooks).
Würde AMD eine halbwegs konkurrenzfähige µ-Arch haben, könnte man sicherlich 15-20 % Marktanteil in diesen Sparten holen. Die sind sehr profitabel.
Ansonsten hat AMD noch die Chance in den SFF Bereich zu gehen. Da muss man aber wirklich super hohe Stückzahlen liefern, damit man noch etwas verdient. Die Konkurrenz ist dort sehr hart.
IMO gibt es keinen einfachen Weg aus der Misere. Am Ende brauchen sie für jede Richtung, in die sie gehen könnten ein sehr sehr gutes Produkt, um Erfolg zu haben. Und das konstant (also über Jahre hinweg).
fondness
2014-01-30, 11:31:54
Calxedas modernster ARM-Server Chip wurde im alten 40nm Prozess gefertigt, hatte nur einen A9 ohne 64-bit Support und war auch sonst in keiner Hinsicht konkurrenzfähig.
robbitop
2014-01-30, 13:23:17
Es gab auch eine modernere Version mit A15 und 28 nm:
http://www.anandtech.com/show/7265/intels-second-generation-microserver-soc
Die Frage ist, ob ein A57 (ARMv8) so viel daran ändern. Für mich stellt sich die Frage, wie groß und wie Profitabel dieser Markt in Wahrheit ist.
Wieviel Software gibt es für ARMv8 in diesem Segment? Wäre dort ein schmaler x86-64 Prozessor wie Baytrail nicht besser?
fondness
2014-01-30, 13:57:18
Das Ding wurde Ende 2013 vorgestellt und hat nie den Markt erreicht. Der Markt ist aktuell natürlich noch überschaubar, verzeichnet aber enorme Wachstumsraten.
robbitop
2014-01-30, 13:58:48
Dennoch stellt sich die Frage nach existierender Software für ARMv8 und der Größe dieses Marktes.
Dennoch stellt sich die Frage nach existierender Software für ARMv8 und der Größe dieses Marktes.
Ja das ist der Pferdefuß, den die ARM-Leute aber mit dem Linaro-Projekt ziemlich offensiv angehen:
Von letzten Nov:
Linuxunterstützung für ARMs 64-Bit-Architektur wächst | Planet 3DNow! (http://www.planet3dnow.de/cms/5399-linuxunterstuetzung-fuer-arms-64-bit-architektur-waechst/).
robbitop
2014-01-30, 14:48:33
Linaro ist ja nur für das Umfeld zuständig. Die Applikationen müssen dennoch dafür entwickelt werden. Das wird, wenn es finanziell überhaupt erfolgreich wird, mit langem Atem verbunden sein.
Linaro ist ja nur für das Umfeld zuständig. Die Applikationen müssen dennoch dafür entwickelt werden. Das wird, wenn es finanziell überhaupt erfolgreich wird, mit langem Atem verbunden sein.
Naja .. sie zielen auf kleine Server, die laufen doch sowieso zu 95% unter Linux und dort gibts dann Opensource -> Neucompilieren (testen) und fertig.
Dass es Spezialsoftware wie Cinema4D nicht geben wird ist klar, ist aber auch gar nicht geplant.
Was meinst DU denn genau mit "Applikationen"?
robbitop
2014-01-30, 14:52:19
Applikationen = Anwendungen für den gewünschten Anwendungsfall. Nur ein OS allein bringt einem noch wenig. Die Mehrzahl der Anwendungen in diesem Segment ist doch sicher durch andere ISA geprägt. Dinge wachsen leider oftmals historisch... ;)
Lol, was Applikationen sind weiss ich, ich hätte gerne von Dir gewusst, wo Du Probleme siehst.
Wenn Du nichts Konkretes nennen kannst, dann würde ich mal einfach behaupten, das die Dir vorschwebenden Anwendungsfälle außerhalb von ARMs aktuellem Zielgebiet liegen.
Das Zielgebiet sind kleine Webserver, da muss man nur nen LAMP-Stack und Webzeugs zum Laufen bringen, mehr nicht.
Skysnake
2014-01-30, 20:46:13
Applikationen = Anwendungen für den gewünschten Anwendungsfall. Nur ein OS allein bringt einem noch wenig. Die Mehrzahl der Anwendungen in diesem Segment ist doch sicher durch andere ISA geprägt. Dinge wachsen leider oftmals historisch... ;)
Die ganzen ARM-Dinger sind aber hauptsächlich rein für Virtualisierung mit Fail-Over und eben als Datengräber, sowie Webserver gedacht.
Son ARM-/Micro-Server-Ding kaufste dir nicht wegen nen paar Stück, sondern eher Rackweise. Ansonsten ist es auch gar nicht den Aufwand wert.
Da hängt man sich halt an Google, Facebook und noch ein paar Große ran und hofft bei denen eben Punkten zu können durch ihre Einsparungen.
fondness
2014-01-30, 21:02:42
Artikel von AnandTech, interessant das der Chip von Globalfoundries kommt:
http://www.anandtech.com/show/7724/it-begins-amd-announces-its-first-arm-based-server-soc-64bit8core-opteron-a1100
Der Speichercontroller unterstützt sowohl DDR3 als auch DDR4.
fondness
2014-02-05, 14:58:06
Ein ausführliches Interview mit Feldman, wo er auch darauf eingeht warum ARM-Server:
When you take the next step and use those observations to create a bounding box for your future, we ask, “What have we learned from 50 years of the history of compute?” Smaller, high volume, lower cost parts always win. That’s what we’ve learned. That’s how the mainframes were beaten by the micros, and the micros by the minis, and the minis by the workstations, and the workstations by x86.
Where I began in this industry, I was the first non-engineer and the only PC in the building. Everyone else had Sun workstations. Now we have 6,000 engineers, maybe 5,000 engineers, and not one of them has a workstation. All of them have access to x86 and use it, because it was smaller and cheaper and higher volume.
When we think about that, we say, “ARM has those advantages on x86.” There were eight billion ARM processors shipped in 2012, compared to 13 million server parts, plus or minus. ARM amortizes its R&D over hundreds of partners. Intel amortizes its R&D over Intel. We amortize ours over us in the x86 world. The ecosystem that has produced in the handhelds and the clients is remarkable.
What we’ve seen is exactly this pattern of the small nibbling their way up. Intel was sure it would win the phone, and got clobbered. Abject failure. Not once, but three times. ARM nibbled up from sensors, up into the phone, and from the phone up into the pad, and from the pad it’s working into the Chromebook. In its wake it’s laying waste to the client side. At first everybody says it’s underpowered, there’s no software, and then three years later everybody says, “Why would we buy something else?”
We see that same pattern nibbling up all the way into the server space. We’re throwing gas on that fire by announcing an eight-core ARM server part. We’ll be sampling it in a few weeks. Those are the ARM 857. It’s a remarkable part. It’s the only 28-nanometer ARM server part from a vendor who’s ever built a server part before. It’s hardened for servers. It uses all the IP blocks we’ve deployed in millions of servers over the years, all the RAS functionality, all the error correction, the ECC, the high-performance memory controller, all the technologies that servers have demanded. In addition, it supports a huge amount of DRAM, 128 gigs of DRAM. That’s four times what Intel’s premier single-socket part can support.
http://venturebeat.com/2014/02/04/amd-micro-server-boss-welcomes-the-age-of-arm-based-servers-interview/
Das einzige was mich an ARM echt stört ist das scheußliche Speichermodell. Das ist absolute Steinzeit. Überhaupt keine Garantien was Ordnung von Loads und Stores angeht. Das hat x86 aus historischen Gründen richtig gemacht.
Das einzige was mich an ARM echt stört ist das scheußliche Speichermodell. Das ist absolute Steinzeit. Überhaupt keine Garantien was Ordnung von Loads und Stores angeht. Das hat x86 aus historischen Gründen richtig gemacht.
Historisch? Hört sich alt an .. ist das noch ne CISC <> RISC-Geschichte?
Historisch? Hört sich alt an .. ist das noch ne CISC <> RISC-Geschichte?
Nein. RISC-Architekturen neigen nur dazu weniger strikte memory order zu haben. Das heißt aber nicht, dass es was mit CISC oder RISC zu tun hätte. Moderne SPARCs sind zum Beispiel auch vernünftig.
Skysnake
2014-02-05, 19:38:44
und manch x86 hat nen be... memory ordering...
Nö. x86 hat in allen Implementierungen das gleiche memory modell (abgesehen von uraltem Winchip-Kram).
Skysnake
2014-02-05, 20:22:55
biste dir da auch GANZ sicher? ;)
Ja, auch Xeon Phi. Soweit ich weiß jedenfalls. Wenn nicht, dann schande über Intel.
Das sagt die Doku:
4.2.18.1 Memory Ordering Instructions
The Intel® Xeon Phi™ coprocessor memory model is the same as that of the Intel® Pentium processor. The reads and
writes always appear in programmed order at the system bus (or the ring interconnect in the case of the Intel® Xeon
Phi™ coprocessor); the exception being that read misses are permitted to go ahead of buffered writes on the system bus
when all the buffered writes are cached hits and are, therefore, not directed to the same address being accessed by the
read miss.
The Intel MIC architecture invests more heavily in L1 and L2 caches compared to GPU architectures. The Intel Xeon Phi coprocessor implements a leading-edge, very high bandwidth memory subsystem. Each core is equipped with a 32KB L1 instruction cache and 32KB L1 data cache and a 512KB unified L2 cache. These caches are fully coherent and implement the x86 memory order model.
Auf ARM ist alles kreuz und quer. Man hat null Garantien ohne überall Fences hinzupacken wo man muss.
Oder auf was spielst du jetzt an? Falls es doch was anders ist, dann raus mit der Sprache. Mir ist nix bekannt.
Nö. x86 hat in allen Implementierungen das gleiche memory modell (abgesehen von uraltem Winchip-Kram).
Aus nem Wikipedia PDF (http://www.rdrop.com/users/paulmck/scalability/paper/ordering.2007.09.19a.pdf):
x86
Since the x86 CPUs provide “process ordering” so that
all CPUs agree on the order of a given CPU’s writes to
memory, the smp wmb() primitive is a no-op for the
CPU [7]. However, a compiler directive is required to
prevent the compiler from performing optimizations that
would result in reordering across the smp wmb() prim-itive.
On the other hand, x86 CPUs have traditionally given
no ordering guarantees for loads, so the smp mb() and
smp rmb() primitives expand to lock;addl. This
atomic instruction acts as a barrier to both loads and
stores.
More recently, Intel has published a memory model
for x86 [8]. It turns out that Intel’s actual CPUs enforced
tighter ordering than was claimed in the previous specifications, so this model is in effect simply mandating the earlier de-facto behavior. However, note that some SSE instructions are weakly ordered (clflush and non-temporal move instructions [6]). CPUs that have SSE can use mfence for smp mb(), lfence for smp rmb(), and sfence for
smp wmb().
A few versions of the x86 CPU have a mode bit
that enables out-of-order stores, and for these CPUs,
smp wmb() must also be defined to be lock;addl.
Although many older x86 implementations accommodated self-modifying code without the need for any special instructions, newer revisions of the x86 architecture no longer require x86 CPUs to be so accommodating.
Interestingly enough, this relaxation comes just in time
to inconvenience JIT implementorsDie Quellen:
[6] I NTEL CORPORATION. IA-32 Intel Architecture
Software Developer’s Manual Volume 2B: In-struction Set Reference, N-Z, 2004. Available:
ftp://download.intel.com/design/
Pentium4/manuals/25366714.pdf
[Viewed: February 16, 2005].
[7] I NTEL CORPORATION. IA-32 Intel Architec-ture Software Developer’s Manual Volume 3:
System Programming Guide, 2004. Available:
ftp://download.intel.com/design/
Pentium4/manuals/25366814.pdf
[Viewed: February 16, 2005].
[8] I NTEL CORPORATION. Intel 64 Architec-ture Memory Ordering White Paper, 2007.
Available: http://developer.intel.
com/products/processor/manuals/
318147.pdf [Viewed: September 7, 2007Bisher dachte ich die "memory disambiguity" der neuen CPU-Architekturen wäre ein Feature ...
Ansonsten:
Was hälst Du von load-acquire/store-release bei ARMv8?
Tropfen auf den heißen Stein oder eher in Richtung kühles Bier (Kölsch^^)?
Und was steht da jetzt was ich nicht gesagt hätte?
Bei ARMv8 ist es gut, dass es geordnete stores/loads überhaupt gibt, aber man muss trotzdem höllisch aufpassen, dass man sie auch an den richtigen Stellen einsetzt.
Mal was von Herb Sutter dazu (C++ Comittee Member):
Dave: Synchronizing using mutexes/cvs is what we prefer to teach people to use by default. Programming using SC atomics is indeed experts-only difficulty, but unfortunately it’s also justified more often than I would like (e.g., DCL, reference counting, and several other common patterns some of which should be wrapped in types but can’t always be) and so it turns out that we still have to teach SC atomics techniques to advanced-but-mainstream C++ programmers. However, programming using weaker-than-SC atomics is yet another major level of difficulty beyond that, and I don’t know if there are 100 people in the world who can reliably use those directly; I’m still trying to discourage resorting to them, although there currently are performance reasons to reach for them on ARMv7 and POWER. There is a difference of opinion among experts as to whether weaker-than-SC atomics are fully going away or not (e.g., they are lingering in 1000+ core count supercomputing applications), but with ARMv8 in particular the industry momentum in mainstream processors is going in the direction of seeing the performance carrot shrinking and disappearing for resorting to weaker-than-SC models.
Ach sorry war spät gestern. Dachte das Speichermodell hätte sich bei x86 geändert, aber jetzt beim nochmaligen Lesen sehe ich, dass das implementierte Modell immer das gleiche war, nur die Doku war fehlerhaft (und hat sich geändert).
Wobei man eventuell noch über die SSE-Befehle reden sollte, wieso tanzen die aus der Reihe?
Es gibt streaming stores in SSE die am Cache vorbei schreiben um den nicht zu thrashen. Auf die musst du syncen, wenn du sie (manuell) benutzt.
Nützlich zum Beispiel um das finale Resultat in einen Framebuffer zu schreiben.
Skysnake
2014-02-07, 11:17:51
Auf ARM ist alles kreuz und quer. Man hat null Garantien ohne überall Fences hinzupacken wo man muss.
Oder auf was spielst du jetzt an? Falls es doch was anders ist, dann raus mit der Sprache. Mir ist nix bekannt.
Musste bis zum Sonntag mindestens warten, und du verlinkst am Besten kurz die Docs auf die du zugreifen kannst. Ich such dann nach der entsprechenden Stelle.
Skysnake
2014-02-07, 12:28:20
Musste bis zum Sonntag mindestens warten, und du verlinkst am Besten kurz die Docs auf die du zugreifen kannst. Ich such dann nach der entsprechenden Stelle.
Ok, es gibt halt zwei Sachen:
1.
4.2.18.1
Memory Ordering Instructions
The Intel® Xeon Phi™ coprocessor memory model is the same as that o
f the Intel® Pentium processor. The reads and
writes always appear in programmed order at the system bus (or the ring interconnect in the case of the Intel® Xeon
Phi™ coprocessor); the exception being that read misses are permitted to go ahead of buffered
writes on the system bus
Intel® Xeon Phi™ System Software Developer’s Guide
Page
121
when all the buffered writes are cached hits and are, therefore, not directed to the same address being accessed by the
read miss.
As a consequence of its stricter memory ordering model, the Intel® Xeon Phi™ coprocessor does no
t support the
SFENCE, LFENCE, and MFENCE instructions that provide a more efficient way of controlling memory ordering on other
Intel processors.
While reads and writes from an Intel® Xeon Phi™ coprocessor appear in program order on the system bus, the
compiler
can still reorder unrelated memory operations while maintaining program order on a single Intel® Xeon Phi™
coprocessor (hardware thread). If software running on an Intel® Xeon Phi™ coprocessor is dependent on the order of
memory operations on a
nother Intel® Xeon Phi™ coprocessor then a serializing instruction (e.g., CPUID, instruction with
a LOCK prefix) between
the memory operations is required
to guarantee completion of all memory accesses issued prior
to the serializing instruction before any
subsequent memory operations are started
und ansonsten gibt es noch gewisse Einschränkungen bzgl dem Package powerstate. XeonPhi kann nicht immer puts entgegennehmen, das such ich jetzt aber nicht noch extra raus. Steht irgendwo unter power management.
fondness
2014-02-11, 16:54:26
Ein paar neue Details und auch was zum Aufbau: http://www.planet3dnow.de/cms/7977-details-zu-amd-a1100-opteron-seattle-16-kerne/
http://imagizer.imageshack.us/v2/xq90/706/vdj4.png (https://imageshack.com/i/jmvdj4p)
fondness
2014-08-11, 19:22:49
Neue Infos zu den ARM Opterons:
http://www.anandtech.com/show/8362/amds-big-bet-on-arm-powered-servers-a1100-revealed
http://s1.postimg.org/46evg7vn3/seattle_SOC_575px.jpg (http://postimage.org/)
http://s18.postimg.org/s3dcrt995/seattle_ARM_cores_575px.jpg (http://postimage.org/)
http://s18.postimg.org/mggzuc6qh/seattle_block_diagram_575px.jpg (http://postimage.org/)
http://s29.postimg.org/gonof2hw7/seattle_ccp_575px.jpg (http://postimage.org/)
http://s29.postimg.org/snul8my3b/seattle_floor_plan_575px.jpg (http://postimage.org/)
http://s29.postimg.org/u463qs107/seattle_memory_575px.jpg (http://postimage.org/)
http://s29.postimg.org/r0017q9lj/seattle_scp_1_575px.jpg (http://postimage.org/)
=Floi=
2014-08-11, 21:09:20
Zielpreis und wo das teil untergebracht wird wäre auch noch wissenswert. ich hoffe die deseignen es skalierbar, damit es auch boards mit 16-128 solcher prozessoren gibt.
fondness
2014-08-11, 22:04:24
Das Dev-Kit für Entwickler kostet $3000, billig wird der Spaß also wohl kaum. Scheint im übrigen auch so als wäre Seattle der erste A57 SoC überhaupt.
Auf Deutsch:
AMD präsentiert ARM-Opteron Seattle auf der Hot Chips 26 | Planet 3DNow!.
(http://www.planet3dnow.de/cms/11149-amd-praesentiert-arm-opteron-seattle-auf-der-hotchips26/)
mboeller
2014-08-12, 07:39:52
klein wird die CPU ja nicht.
Wenn man den Floorplan mal "wörtlich" nimmt und für den L2-Cache 6mm² annimmt kommt die CPU auf ~200mm²
fondness
2014-08-22, 11:19:09
Dev-Kit verfügbar:
http://developer.amd.com/community/blog/2014/08/20/amd-opteron-a1100-series-developer-kit-now-available/
fondness
2014-09-30, 14:58:21
This session focuses on AMD’s ARM 64-bit strategy and the role of Oracle’s JVM in that strategy. Additionally, it highlights AMD’s leadership in heterogeneous computing with accelerated processing units by integrating central processing units (CPUs) and graphics processing units (GPUs) on the same piece of silicon. During the presentation, AMD demonstrates ARM 64-bit hardware running Oracle’s JVM and provides an update on AMD’s OpenJDK project, Sumatra.
https://oracleus.activeevents.com/2014/connect/search.ww?eventRef=javaone#loadSearch-event=null&searchPhrase=leendert&searchType=session&tc=0&sortBy=&p=&i%2810009%29=10111
http://www.planet3dnow.de/cms/12075-first-arm-cortex-a57-based-hadoop-demonstration-achieved-on-amd-opteron-a-series-platform/
mksn7
2014-10-02, 00:48:40
Es gibt streaming stores in SSE die am Cache vorbei schreiben um den nicht zu thrashen. Auf die musst du syncen, wenn du sie (manuell) benutzt.
Ist das bei x86 non temporal stores generell so? Der Xeon Phi hat fuer non-temporal stores neben vmovnrapd (no read) extra auch noch vmovnrngoapd (no read, no global ordering), wo keine strikte memory ordering garantie mehr besteht. vmovnrapd ist deutlich langsamer als vmovnrngoapd. Aber non temporal stores auf dem Phi sind sowieso speziell.
Ich haett jetzt gedacht, dass vmovnrngoapd da die Ausnahem ist und das Verhalten von vmovnrapd der standard.
fondness
2015-04-21, 16:49:52
Mal wieder was neues zu Seattle:
http://s17.postimg.org/4bdp386i7/AMD_A1100_series_617x347.png (http://postimage.org/)
http://s17.postimg.org/ij3drvj73/AMD_A1100_series_price_617x347.png (http://postimage.org/)
Laut den letzten Conference Call soll der Chip im H2/2015 endlich verfügbar sein.
y33H@
2015-04-21, 16:54:39
Quelle und so: http://www.whd.global/downloads/2015-global/mFtag2d.pdf
EDIT
Im PDF steht übrigens Xeon D-1540 und nicht Atom?!
http://abload.de/thumb/2015-04-21_165758x2s4r.png (http://abload.de/image.php?img=2015-04-21_165758x2s4r.png)
Neu ist (unter) 45W und Preis ... dafür weitaus lahmer als der Xeon D ...
EDIT2
Aha, das PDF online ist älter, deine Slides neuer. Und in deinem kostet der A1100 viel viel weniger :ugly:
Quelle?
EDIT3
Hast es wohl von Semiaccurate, deren PDF ist neuer.
fondness
2015-04-21, 17:48:36
Ja genau.
y33H@
2015-04-21, 18:16:17
Dann frage ich mal das neuere an ^^
Windi
2015-04-21, 18:38:14
Nur 4-8 Kerne?
Ich dachte die nehmen ARM Kerne, um mal richtig Viele auf einen Chip quetschen zu können.
Hätte man das nicht auch mit den sparsamen Jaguar/Puma Kernen hin bekommen?
dildo4u
2015-04-21, 18:45:17
Quelle und so: http://www.whd.global/downloads/2015-global/mFtag2d.pdf
EDIT
Im PDF steht übrigens Xeon D-1540 und nicht Atom?!
http://abload.de/thumb/2015-04-21_165758x2s4r.png (http://abload.de/image.php?img=2015-04-21_165758x2s4r.png)
Neu ist (unter) 45W und Preis ... dafür weitaus lahmer als der Xeon D ...
EDIT2
Aha, das PDF online ist älter, deine Slides neuer. Und in deinem kostet der A1100 viel viel weniger :ugly:
Quelle?
EDIT3
Hast es wohl von Semiaccurate, deren PDF ist neuer.
Die vergleichen ARM mit Boardwell Cores lol AMD.
y33H@
2015-04-21, 19:07:31
Nein, das ist die alte Slide. Die neue stellt den A1100 gegen einen C2750.
Intel selbst sieht den C2750 klar vor einem X-Gene. Der ähnelt mit 8x A57 @ 2,4 GHz dem A1100 grob.
51680 51681
Sollte AMDs A1100 deutlich günstiger und sparsamer sein als der X-Gene, so wäre der Opteron durchaus eine Alternative zum C2750.
Sparsamer als der X-Gene dürfte er sein, denn der X-Gene 1st Gen (http://www.hotchips.org/wp-content/uploads/hc_archives/hc26/HC26-11-day1-epub/HC26.11-4-ARM-Servers-epub/HC26.11.430-X-Gene-Singh-AppMicro-HotChips-2014-v5.pdf) ist 40nm, der A1100 hingegen 28nm.
maximus_hertus
2015-04-21, 20:14:47
Ich gehe mal davon aus, dass es die ARM Opterons nicht im Retail-Channel zu kaufen geben wird? Gibt's dazu Infos?
Skysnake
2015-04-21, 21:12:18
Ich sehe vor allem die 2x 10GBit/s Netzanschlüsse als wirklich positiv an. Da sollte sich so manches Einsatzfeld ergeben. Leider gibt es "nur" 14 SATA Ports. Da fehlt noch der SAS Raid Controller, dann wäre das Ding wohl ziemlich interessant für fette Lustre Installationen.
y33H@
2015-04-22, 13:55:06
AMD sagt, die bei den WHDs verlinkten Slides sind die korrekten, die von Semiaccurate die veralteten (wurden daher bei Slideshare offline genommen).
“We believe the AMD Opteron A1100 should be positioned between Intel ATOM and Intel Xeon-D given it is an higher performing and better integrated solution than Intel ATOM, while being lower power, better integrated for storage, at a much lower cost than Intel Xeon-D for the hosting market segment”.
Nakai
2015-04-23, 14:07:05
Ich sehe vor allem die 2x 10GBit/s Netzanschlüsse als wirklich positiv an. Da sollte sich so manches Einsatzfeld ergeben. Leider gibt es "nur" 14 SATA Ports. Da fehlt noch der SAS Raid Controller, dann wäre das Ding wohl ziemlich interessant für fette Lustre Installationen.
https://www.apm.com/products/data-center/x-gene-family/x-gene/
X-Gene hat 4 10G Ethernet, also nichts besonderes.
AMD muss wohl über den Preis gehen.
Ich sehe vor allem die 2x 10GBit/s Netzanschlüsse als wirklich positiv an. Da sollte sich so manches Einsatzfeld ergeben. Leider gibt es "nur" 14 SATA Ports. Da fehlt noch der SAS Raid Controller, dann wäre das Ding wohl ziemlich interessant für fette Lustre Installationen.
Hardware-RAID ist tot.
Das löst man heute auf Dateisystem-Ebene. Ist schneller und sicherer.
Ganon
2015-04-24, 11:04:35
Wenn man vom RAID (vorzugsweise 5 oder 6) booten möchte, dann sinken aber die Möglichkeiten. Windows fällt ganz raus, bei FreeBSD bleibt nur ZFS (hohe RAM-Anforderungen) und dann halt noch Linux mit btrfs (hatte letztens erst wieder einen Deadlock-Bug) oder mdadm. Wobei der Weg über mdadm halt nicht "auf Dateisystemebene" ist, soweit ich weiß.
Aber ja, ich würde auch Software-RAID vorziehen. Bei mir ist es ja FreeBSD/ZFS.
Brillus
2015-04-24, 17:53:35
Hardware-RAID ist tot.
Das löst man heute auf Dateisystem-Ebene. Ist schneller und sicherer.
Sicherer verstehe ich, aber warum soll das schneller sein?
Die Hardware-RAID-Controller verhindern dass der Kernel Controller über Command-Queuing hat und bei "billigen" Controllern ohne NVRAM gibt es das Write-Hole-Problem:
https://blogs.oracle.com/bonwick/entry/raid_z
Skysnake
2015-04-24, 18:14:24
Gibt es überhaupt "billige" SAS Controller? :confused:
Ich dachte da jetzt eher an so etwas http://www.lsi.com/products/host-bus-adapters/Pages/sas-9300-16i.aspx
Da dann noch Edge Expander Boxen dran und ab geht die Luzi.
robbitop
2015-04-24, 18:20:37
Absolut. Billiger als billige SATA Controller. Ich habe einen, der 8x SAS HDDs unterstützt, der neu nur 110 € € kostet.
Skysnake
2015-04-24, 18:30:16
Wer redet denn von SATA?
robbitop
2015-04-24, 18:33:43
Das war eine ANALOGIE.
SATA = billiger Consumerkram
SAS = professional.
Du fragtest ob es billige SAS Controller gab. Da passt der vergleich, dass die billigsten SAS Controller sogar noch billiger als SATA Controller sind.
Skysnake
2015-04-24, 20:02:45
Deswegen sage ich ja "billig".
Man muss ja nicht den letzten Dreck kaufen, wobei ich mir kaum vorstellen kann, das es bei SAS Controllern überhaupt ernsthaften Müll gibt.
Gibt es überhaupt "billige" SAS Controller? :confused:
Ich dachte da jetzt eher an so etwas http://www.lsi.com/products/host-bus-adapters/Pages/sas-9300-16i.aspx
Da dann noch Edge Expander Boxen dran und ab geht die Luzi.
Das Ding hat kein NVRAM, also genau das Problem was ich beschrieben habe. Schreibt man weniger als die Stride-Size muss das Ding erstmal lesen.
Außerdem hat es doch auch gar kein Hardware-RAID, wtf?
stav0815
2015-04-25, 11:06:43
Naja, SAS-Controller ungleich RAID-Controller. Wie bei SATA übrigens auch...
robbitop
2015-04-25, 11:23:30
Ich meinte in beiden Fällen natürlich RAID.
Naja, SAS-Controller ungleich RAID-Controller. Wie bei SATA übrigens auch...
O'rly
R.I.P.
2015-04-25, 11:59:31
Auf Semiaccurate laut Thomas Ryan spricht man von 171 Dollar pro Stück A1100, was der Hammer wäre im Vergleich zu den Kosten von Intel.
http://semiaccurate.com/2015/04/21/amds-opteron-a1100-series-to-sell-for-171/
Auf Semiaccurate laut Thomas Ryan spricht man von 171 Dollar pro Stück A1100, was der Hammer wäre im Vergleich zu den Kosten von Intel.War das nicht der Kasper, der bei der Erklärung zu den ACEs von AMD's Hawaii deren 8 Stück den 32 Queues von Maxwell 2 gegenübergestellt hat, während dieHawaiis bei einem Apples-to-Apples Vergleich eigentlich 64 Queues aufweisen würden? Auf die Aussage von so einem würde ich prinzipiell nichts geben.
[edit] Das war Ryan Smith auf anandtech, diesen Post ignorieren please
y33H@
2015-04-25, 12:25:07
Auf Semiaccurate laut Thomas Ryan spricht man von 171 Dollar pro Stück A1100, was der Hammer wäre im Vergleich zu den Kosten von Intel.
http://semiaccurate.com/2015/04/21/amds-opteron-a1100-series-to-sell-for-171/Die haben die falschen Slides von Slideshare gefischt, da sind sie mittlerweile offline und der Artikel bei S|A mittlerweile auch.
Die korrekten Slides mit (unter) 581 USD gibt's hier: http://www.golem.de/news/opteron-a1100-amd-moechte-intels-luecke-im-server-markt-ausnutzen-1504-113676.html
51725
R.I.P.
2015-04-25, 13:06:08
Die haben die falschen Slides von Slideshare gefischt, da sind sie mittlerweile offline und der Artikel bei S|A mittlerweile auch.
Die korrekten Slides mit (unter) 581 USD gibt's hier: http://www.golem.de/news/opteron-a1100-amd-moechte-intels-luecke-im-server-markt-ausnutzen-1504-113676.html
51725
Oha...danke!
y33H@
2015-04-25, 16:23:00
Wobei das schon komisch ist ... Milchmädchen-Theorie: Der A1100 kostet unter 171 USD, aber AMD dachte, man könne ihn ja wegen 8C, mehr Sata und weniger TDP auch gegen den viel teureren Xeon D stellen, das sieht besser aus. Ansonsten wüsste ich nicht, warum eine (mit neuerem Datum versehene) Slide ihn auch gegen Atom stellt. Jemand hat sich dabei ja was gedacht, nehme ich zumindest an.
Ravenhearth
2015-04-25, 16:38:56
Auffallend ist, dass auf der Atom-Folie <171 steht, auf der mit Xeon aber <<<581.
Unicous
2015-04-25, 16:49:10
@ y33H@
Eben genau das hat man sich gedacht. Man konkurriert einerseits gegen den Atom bei der Leistung und preislich und in Sachen I/O und TDP gegen einen Xeon. Ob das den Kunden überzeugt, ist natürlich eine andere Sache.:freak:
@Nakai
Das mit den 4 10 G Ports beim X-Gene stimmt so auch nicht ganz.
•
One 10G Ethernet port (XFI)
•
Two 10/100/1G Ethernet ports (SGMII)
•
One 10/100/1G Management Ethernet port
(RGMII)
https://www.apm.com/docs/XC1-Plus-Brief.PDF
Außerdem sind es bei Seattle backplane ethernet ports, das wenn ich mich nicht irre ein Alleinstellungsmerkmal wäre.
y33H@
2015-04-25, 16:55:40
Auffallend ist, dass auf der Atom-Folie <171 steht, auf der mit Xeon aber <<<581.Ja, genau. Bei < meint es "günstiger" und bei <<< "sehr sehr viel günstiger".
Eben genau das hat man sich gedacht. Man konkurriert einerseits gegen den Atom bei der Leistung und preislich und in Sachen I/O und TDP gegen einen Xeon. Ob das den Kunden überzeugt, ist natürlich eine andere Sache.Vor allem, was zahlt der Kunde real an Intel wenn er den Atom oder den Xeon haben will? Listenpreise sind IMHO witzlos bei solchen Produkten.
Unicous
2015-04-25, 17:24:57
Meines Erachtens sind Listenpreise bei Consumer-Produkten witzlos. Denn hier geht man gerne mal mit der Marge runter(und natürlich werden deutlich mehr Einheiten verkauft). Im Serverbereich ist die Marge natürlich deutlich höher. Ich denke nicht, dass ein Avoton so stark im Preis sinkt wenn man mehr als 1000 Einheiten kauft.
Und der Preis für den Chip oder das Board ist vor allem wichtig für die TCO (total cost of ownership) Frage? Was kostet mich das gesamte System über x-Monate/Jahre.
Das ist die wichtigste Metrik für den Kunden.
Ravenhearth
2015-05-06, 21:05:54
Kommt im 2. Halbjahr 2015. Hat ja auch gedauert.
51850
y33H@
2015-05-06, 21:30:23
Der HPC-Chip mit iGPU klingt fett. Das dürfte das 300W-Teil sein, mit evtl Zen und ieiner GNC-Lösung.
Skysnake
2015-05-06, 21:36:51
Wann wurde etwas über einen HPC Chip gesagt? Ich habe dazu nicht wirklich was gehört.
Es wurde ja nur mal kurz was von Exavator 18C APU gesagt, aber dann kam nichts dazu, oder ich habe es zumindest nicht bewusst wahrgenommen :ugly:
Ravenhearth
2015-05-06, 21:52:50
Da war nichts von einem 18C Excavator.
fondness
2015-06-28, 10:00:58
AMD kündigt „preisgünstiges” Board mit dem 64-Bit-ARM-Quadcore Opteron A1100 an
http://www.planet3dnow.de/cms/17824-amd-kuendigt-preisguenstiges-board-mit-dem-64-bit-arm-quadcore-opteron-a1100-an/
=Floi=
2015-06-28, 18:57:37
3 jahre später! was machen die bei amd den ganzen tag eigentlich?
ohne gpu kann man das teil doch vergessen.
StefanV
2015-06-28, 19:11:09
aber nur für Enduser/Android. Nicht aber für Storage Dinge und so weiter. Da klatscht man eh einen entsprechend ATspeed Chip drauf und gut is...
Ist ja wohl wieder nur ein "Dev"-Beispiel, sehr merkwürdiger Formfaktor und begrenzt I/O im Vergleich zur eigentlich vorhandenen Möglichkeit. Hm, wer kauft sowas?
R.I.P.
2015-10-15, 16:28:28
http://dresdenboy.blogspot.de/2015/10/amds-arm-based-hierofalcon-soc-sighted.html
Seattle Benchmarks
Hier doch auch :)
http://www.planet3dnow.de/cms/20539-erste-benchmarks-des-seattle-nachfolgers-hierofalcon/
Arnoldie
2016-01-14, 15:43:52
Und da sind sie wohl:
http://www.heise.de/newsticker/meldung/Jetzt-kommt-er-wirklich-AMDs-ARM-Opteron-A1100-3070297.html
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.