AMD will 2010 Intels Atom-Plattform Konkurrenz machen

SileX86

Enthusiast
Thread Starter
Mitglied seit
02.03.2006
Beiträge
784
Ort
Zelt
<p><img style="float: left; margin: 10px;" src="images/stories/logos/amd_2009.gif" alt="amd_2009" height="100" width="100" />Der Trend zu kleinen, kompakten und stromsparenden Computern, sowohl im mobilen als auch im Desktop-Sektor, ist derzeit überall zu spüren. <a target="blank" href="http://www.intel.com/#/de_DE_03">Intel</a> hat mit seiner Atom-Plattform eine ideale Basis für solche Produkte im Angebot, doch bei <a target="blank" href="http://www.amd.com/de-de/">AMD</a> fehlt es noch an der passenden Hardware. Dies solch sich laut Dirk Meyer, CEO von AMD, im nächsten Jahr ändern, denn AMD arbeite derzeit an einer neuen Plattform, die im Vergleich zum Atom günstiger sein soll, einen geringeren Stromverbrauch habe und trotz kleinerer Größe, einen höheren...<p><a href="/index.php?option=com_content&view=article&id=12377&catid=34&Itemid=99" style="font-weight:bold;">... weiterlesen</a></p>
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Was ist eigentlich mit dem bereits eingestellten Geode? Wäre eine "Weiterentwicklung" dessen nicht ein gute Basis für dieses Vorhaben?
 
Zuletzt bearbeitet:
"Den" Geode gibt es nicht, das ursprüngliche VIA-Design wurde gegen Ende gegen einen Athlon (XP?) Kern getauscht... Beide Architekturen sind aber viel zu veraltet und würden ein Ziel, den Atom beim Energiesparen und der Leistung zu übertreffen, kaum möglich machen.
Für 100mW idle wie bei einem aktuellen Atom - 2010 soll Moorestown nocheinmal deutlich sparsamer sein - bräuchte es sicher ein komplett neues Design, niedrige Lastverbräuche sind da schon fast der einfachste und unbedeutendste Punkt.

Warum, der Geode basierte doch, wenn ich mich nicht irre, auf dem Athlon XP, und mit dem A64 hat man auch schon gezeigt, dass man Strom sparen kann ;)
Glaube der A64 2000+ (im G2 Stepping) hatte auch nur 10W...

Edit:

8W sogar bloß :fresse:

http://www.tomshardware.com/reviews/Atom-Athlon-Efficient,1997.html


Wie gesagt, dass sind Lastverbräuche. Idle skalieren diese Architekturen selbst bei starken Spannungssenkungen nicht mehr wirklich gut, aber gerade da ist es relevant. Selbst 1-2W Idleverbrauch wären das 10-20x eines Atoms und würde die Laufzeit (bei angenommen ~7-8W Gesamtverbauch eines Netbooks) um 15-25% verringern.
 
Zuletzt bearbeitet:
Warum, der Geode basierte doch, wenn ich mich nicht irre, auf dem Athlon XP, und mit dem A64 hat man auch schon gezeigt, dass man Strom sparen kann ;)
Glaube der A64 2000+ (im G2 Stepping) hatte auch nur 10W...

Edit:

8W sogar bloß :fresse:

http://www.tomshardware.com/reviews/Atom-Athlon-Efficient,1997.html

Hatte da bei P3D was aufgeschnappt:
[...]Intel ließ sich bekanntlich vom Intel Pentium (1993-1997) inspirieren, einem relativ simpel aufgebauten In-Order Prozessor mit nur zwei Integer-Pipelines. Dieses Grundkonzept hat Intel beim Atom in die Neuzeit transportiert und mit aktuellem Herstellungsprozess und ein wenig Nachhilfe in Sachen Features (SIMD-Einheiten, Cache) aufgebohrt. Damit hat der Atom genügend Leistung, um das, was er können soll, zu bewältigen, und für Intel ist er eine Gelddruckmaschine, da so günstig herzustellen ist wie kein anderer x86-Prozessor derzeit. Man darf gespannt sein wie AMD diesen Atom-Konkurrenten realisieren will. Technische Details, ob man sich ebenfalls von einer simpleren Architektur aus der Vergangenheit inspirieren lässt oder einen anderen Weg geht, stehen derzeit noch aus.

Ich denk mal für AMD wäre es zu teuer eine komplett neue Architektur zu entwickeln, aber selbst mit dem sehr sparsamen K8 kommt man nicht ganz an den Atom ran. Daher hier auch Inspiration aus der Vergangenheit...
 
Der Markt ist groß und die Komplexität eines solchen Designs auch weit geringer als bei aktuellen High-End Modellen, rentieren sollte sich also eine solche Investition schon.
Den Atom einfach als Pentium-Abkömmling zu sehen machen sich viele Seiten zu einfach, bis auf die Verwandtschaft des In-Order Designs verbindet die beiden nicht mehr viel bzw. besser gesagt: Es steckt eine ganze Menge zusätzlicher Überlegungen in gewissen Design-Entscheidungen ;) Nur als Beispiel, ein Grund für die relativ schwache Pro-MHz Leistung ist u.a. der Verzicht auf exzessive spekulative Ausführungen wie in allen anderen aktuellen Designs, weil hier das Verhältnis von zusätzlicher Leistung zu erhöhtem Stromverbrauch ins Negative kippt. Soetwas kann man nicht einfach und effizient einem anderen, bestehenden Design beibringen.
 
Nein. Was hat spekulative Ausführung mit der Umsortierung der Befehlskette zu tun? Gar nix...
 
Bei In-Order wird gar nix umsortiert. Insofern fällt auch der Aufwand für spekulative Ausführung praktisch weg. ;)
 
Zuletzt bearbeitet:
Hmm wenn ich mir die Specs des Geode LX/NX bei wikipedia so ansehe, sollte mit aktueller Fertigungstechnik und einigen Erweiterungen(siehe Atom@P3D) doch genug Potential vorhanden sein.

Oder spricht da was dagegen?
 
Bei In-Order wird gar nix umsortiert. Insofern fällt auch der Aufwand für spekulative Ausführung praktisch weg. ;)

So einfach ist es nicht. Der Verzicht auf spekulative Ausführung betrifft nur einen der beiden Decoder des Atoms, eine bewusste Design-Entscheidung.
 
@Mondrial
Geode war doch noch ohne interne NB, oder? Glaube nicht, dass AMD wieder dahin zurück will. Zumindest das könnte dagegen sprechen.

@Undertaker
Das mag ja sein. Der Aufwand ist trotzdem deutlich geringer als bei OoO.
 
Zuletzt bearbeitet:
Bist du dir da sicher? Ich dachte immer, Geode ist K7 basiert. Müsste der also nicht klassisch über FSB angebunden sein?
 
Jo das gilt für den NX, der wird das dann nicht haben. Aber der LX basiert noch auf dem GX, welcher wiederum die gleichen Specs wie der GX2 aufweist.

Und zu dem steht bei wikipedia folgendes:
Der National Geode GX2 ist der Nachfolger des Geode GX1, dieser wurde aber grundlegend überarbeitet und u. a. mit einem größeren L1-Cache, AMDs 3DNow!-Befehlen und einer längeren Pipeline ausgestattet. Auch die FPU wurde verbessert (ist jetzt fully pipelined), und das Speicherinterface des ebenfalls integrierten Speichercontrollers wurde auf DDR-SDRAM geändert.

Edit: Wie gesagt, das ist alles von wikipedia...
 
Das mag ja sein. Der Aufwand ist trotzdem deutlich geringer als bei OoO.

Es geht nur darum, dass es in keinerlei zwingendem Zusammenhang steht - das Beispiel diente zur Verdeutlichung dafür, wie tief Designentscheidungen gehen um die extreme Sparsamkeit zu erreichen - eine simple Herunterskalierung eines bestehenden Designs reicht dafür nicht aus.
 
So einfach ist es nicht. Der Verzicht auf spekulative Ausführung betrifft nur einen der beiden Decoder des Atoms, eine bewusste Design-Entscheidung.
Echt ? Hat der Atom überhaupt zwei Decoder ? Der hat 2 Threads, aber der Decoder wird dabei nicht verdoppelt, oder meinst Du irgendwas andres ?

Sagt mir auf alle Fälle erstmal überhaupt nichts, hast Du vielleicht nen Link ?

@Mondrial:
Die alten Geodes sind asbach ... bevor man das Methusalem Teil mit Cyrix Kern, miserabler FPU, PCI (ja, richtig gelesen, ohne "e") und DDR Kontroller.

Bevor man da was anfaßt bastet man aus aktueller AMD Regaltechnik was eigenes zusammen -> Ontario.

ciao

Alex
 
Dacht ich mir ...

a) schlecht geschrieben und falsch (es sind 3 Dekoder ^^)
b) nix Besondres

Das ist Gang und Gäbe bei modernen CPUs, dass die mehrere Dekoder haben.
Schnelle Fastpath für die häufig verwendeten Befehle und langsame Microcode für die "Orchideen"-instruktionen.

Schau mal dort, da ist es besser erklärt:
http://arstechnica.com/hardware/news/2008/05/risc-vs-cisc-mobile-era.ars/2

Mit Spekulation hat das nichts zu tun, keine Ahnung, was für den Author da so "obvious" ist:
The fast path obviously employs some speculative decoding
ciao

Alex
 
Ach, deswegen hast du "überhaupt 2?" gefragt, weil du wusstest das er 3 hat? Witzig ;) Anandtech scheint die 2 identischen schlicht zusammengefasst zu haben, es geht hier auch nicht um die absolute Anzahl, sondern um die bewusste Typaufteilung nach energetischen Gesichtspunkten :)
 
Es geht nur darum, dass es in keinerlei zwingendem Zusammenhang steht
Was glaubst du denn, impliziert In-Order? Ich würde gerne erstmal sehen, was im ursprünglichen Design schon alles drin war und was nicht. Dann kannst du immer noch behaupten, man habe extra auf "exzessive spekulative Ausführung" verzichtet.
 
Nun, was denkst du wohl warum der 2. (oder eben 3.) Decoder auf die spekulative Ausführung verzichtet? ;)
 
Wie wäre es du antwortest auf meine :wink: Warum verzichtet man bei den/dem "langsamen" Decoder(n) auf die spekulative Ausführung? Vergiss deine In-Order Argumentation, Anandtech hat den Finger drauf:

"As Intel learned with Banias (Pentium M), the power penalty for incorrect speculation is unacceptable in a device running on a battery. You'll see a number of tradeoffs where speculative performance tricks are sacrificed in order to maintain low power operation with the Atom processor."

Und damit kommen wir wieder zum eigentlichen Thema: Solche Überlegungen, und da mag dieses Beispiel noch recht unbedeutend sein, lassen sich nicht einbringen, wenn schlicht ein bestehendes Desktop-Design herunterskaliert wird - ein heruntergetakteter Athlon, Phenom oder Core 2 oder sonstetwas wird im Verbrauch nie auf ein vergleichbares Niveau kommen, AMDs Atomkonkurrent wird, wenn die Versprechen gehalten werden sollen, etwas neues sein.
 
Zuletzt bearbeitet:
Wie wäre es du antwortest auf meine :wink: Warum verzichtet man bei den/dem "langsamen" Decoder(n) auf die spekulative Ausführung? Vergiss deine In-Order Argumentation, Anandtech hat den Finger drauf:
Wie besagt, die Formulierung von anandtech halte ich für sehr gefährlich.

Die Dekoder haben *nichts* mit OoO zu tun die Dekodieren erstmal. Umsortiert wird gemeinhin später, vor den Execution Units in den Reservation Stations. Dann wenn man schon µOps hat.

Da geht das auch viel effektiver, da die µOps feinkörniger sind, und sich mehr Möglichkeiten ergeben, als wenn man dicke x86 Instruktionen hin und herschieben müßte. Stell Dir mal vor, da käme ne große Microcodeinstruktion, die würde den ganzen Verkehr aufhalten ;-)

Die Dekoder dekodieren nur x86 -> µOp mehr nicht.

Wie Anand da auf spekulativ kommt, weiss nur er allein.

Ach, deswegen hast du "überhaupt 2?" gefragt, weil du wusstest das er 3 hat? Witzi
Ja ich wusste das es da 2+1 Dekoder gibt, und der Gesamtdurchsatz pro Takt 2 µOp max. beträgt. Das da irgendwas verwechselt wurde war mir fast klar, aber ich hab mich gefragt was ;-)

Zu dem "spekulativ" nochmal: In irgendeinem Bericht stand mal, dass Atom auch ausnahmsweise ein paar wenige Befehle OoO ausführen kann, aber größtenteils ist es dennoch ne in-order Architektur.

Ich schau mal, ob ichs noch irgendwo finde...

Edit:
Explizit hab ich den Artikel jetzt nicht gefunden, aber ich glaub das bezog sich aufs Load-to-store forwarding. Das kann Atom auch. Bevor eine ausgeführte Instruktion in den Speicher schreibt, steht die in nem (Schreib)Puffer. Neue Befehle können dort im Puffer nachschauen, ob sie die nagelneuen Werte benötigen und dann gleich aus dem Puffer lesen.
Rein nach in-odern Lehre, müßte das aber erst in den Speicher zurückgeschrieben werden ...

Naja nicht so interessant.

Und damit kommen wir wieder zum eigentlichen Thema: Solche Überlegungen, und da mag dieses Beispiel noch recht unbedeutend sein, lassen sich nicht einbringen, wenn schlicht ein bestehendes Desktop-Design herunterskaliert wird - ein heruntergetakteter Athlon, Phenom oder Core 2 oder sonstetwas wird im Verbrauch nie auf ein vergleichbares Niveau kommen,
Jein ... schau Dir mal VIAs C8 an ... verbraucht, sagen wir mal 10W, bei vernünftiger Taktrate, also schon etwas mehr als der Atom. Aber das Teil ist nur in 65nm produziert. Skalier das mal auf 45nm ...

Nen Unterschied wirds dann immernoch geben, aber was ich sagen will, der OoO Nachteil wird mit sinkender Strukturbreite immer geringer.

Bei Atom zwar auch, aber dort hat das dann nur nen Effekt, dass das Teil vielleicht dann auch fürs handy taugt. (Wobei da die x86->µOp Dekoder ziemlich unpraktisch sind, da sie rel. viel Platz und Strom verbraten)

Wie auch immer, für kleine Notebooks / Netbooks reicht ein 10W dual-core C8 in 45nm ... aus.

Mal schauen was Ontario wird, da hab ich auch gute Hoffnungen. Wenn das wirklich ein einzelner Bulldozerkern mit 2 Clustern + ATi GPU wird, dann wird das in 32nm nicht viel Strom brauchen, aber dennoch eine sehr gute Leistung abliefern.

Atom hat aber auch seine Berechtigung. Um/über 2 GHz herum wird die CPU-Leistung (single-thread) annehmbar, dass sollte mit 32nm auch drin sein.

ciao

Alex
 
Zuletzt bearbeitet:
Jein ... schau Dir mal VIAs C8 an ... verbraucht, sagen wir mal 10W, bei vernünftiger Taktrate, also schon etwas mehr als der Atom. Aber das Teil ist nur in 65nm produziert. Skalier das mal auf 45nm ...

Nen Unterschied wirds dann immernoch geben, aber was ich sagen will, der OoO Nachteil wird mit sinktender Strukturbreite immer geringer.

Bei Atom zwar auch, aber dort hat das dann nur nen Effekt, dass das Teil vielleicht dann auch fürs handy taugt. (Wobei da die x86->µOp Dekoder ziemlich unpraktisch sind, da sie rel. viel Platz und Strom verbraten)

Wie auch immer, für kleine Notebooks / Netbooks reicht ein 10W dual-core C8 in 45nm ... aus.

Mal schauen was Ontario wird, da hab ich auch gute Hoffnungen. Wenn das wirklich ein einzelner Bulldozerkern mit 2 Clustern + ATi GPU wird, dann wird das in 32nm nicht viel Strom brauchen, aber dennoch eine sehr gute Leistung abliefern.

Atom hat aber auch seine Berechtigung. Um/über 2 GHz herum wird die CPU-Leistung annehmbar, dass sollte mit 32nm auch drin sein.

ciao

Alex

Vergiss die Lastverbräuche ;) Zu 95% idelt die CPU im Akkubetrieb oder ist nur zu einem sehr geringen Teil ausgelastet. Genau hier liegen die Stärken des Atom-Designs, 100mW(!) werden hier angegeben für einen 2GHz Z550. Ein X2 250 idlet vergleichsweise bei 6,9W. Lass uns den Speichercontroller abspecken, einen Kern wegnehmen, hier und da Tweaks vornehmen - schaffen wir damit 3W, vielleicht auch 2W Restverbrauch? Schon ein alter Atom N270 schafft 600mW Average(!). Ich bleibe dabei, mit bestehenden Designs ist ein Atom beim Punkt Stromverbrauch definitiv nicht zu erreichen.
 
Vergiss die Lastverbräuche ;) Zu 95% idelt die CPU im Akkubetrieb oder ist nur zu einem sehr geringen Teil ausgelastet. Genau hier liegen die Stärken des Atom-Designs, 100mW(!) werden hier angegeben für einen 2GHz Z550. Ein X2 250 idlet vergleichsweise bei 6,9W. Lass uns den Speichercontroller abspecken, einen Kern wegnehmen, hier und da Tweaks vornehmen - schaffen wir damit 3W, vielleicht auch 2W Restverbrauch? Schon ein alter Atom N270 schafft 600mW Average(!). Ich bleibe dabei, mit bestehenden Designs ist ein Atom beim Punkt Stromverbrauch definitiv nicht zu erreichen.
Ah ok idle ... ok, da hat Atom mit den aggresiven Clock-gating nen Vorteil. Aber das läßt sich auch bei OoO CPUs machen Paradebeispiel das legendäre
Pwrficient:
http://www.energystar.gov/ia/produc...result&usg=AFQjCNFunc814OPoLTqbPVcglyyMQ3NZjw

Zwar auch noch 1W im Nap mode, aber das Ding ist auch "etwas" größer als ein Atom ;-)

Für Ontario sollte sowas auch machbar sein, dort wird ja eben auch ein Chip auf den Stromverbrauch hin entworfen. Die bisherigen CPUs waren ja nur Standarddesign mit geringerer vcore. Geht auch ganz gut, aber nur bis zu nem bestimmten Punkt. Wenn Stromsparen ein Designziel ist, dann geht da viel mehr :)

ciao

Alex
 
Zuletzt bearbeitet:
Wie wäre es du antwortest auf meine :wink: Warum verzichtet man bei den/dem "langsamen" Decoder(n) auf die spekulative Ausführung?
Nochmal, woher weisst du, dass auf irgendetwas verzichtet wurde? Kennst du das zugrunde liegende Design? Schon mal auf die Idee gekommen, dass an der ursprünglichen Pipeline nicht viel geändert wurde, dazu aber einige Errungenschaften der Core Architektur eingeflossen sind, wie eben beim Prefetcher? Und wie Opteron schon sagte, die Decoder haben weniger etwas mit spekulativer Ausführung zu tun. Die sind für die Zerlegung der µOps für die Weiterverarbeitung zuständig
 
Es ist eine ganz einfache Frage: Warum unterstützt es der eine Decoder, warum der andere nicht :)
 
Es ist eine ganz einfache Frage: Warum unterstützt es der eine Decoder, warum der andere nicht :)
Das ist keine Frage, Frage ist nur was Anand geritten hat so nen Käse zu schreiben.

Was die beiden Decoder machen steht oben, ein Fastpath und ein Microcode Path. Warum das so ist hab ich auch geschrieben.

Ein Dekoder dekodiert ... sagt schon der Name ... mehr nicht.

Punkt. Schluss, Ende der Diskussion ;-)

ciao

Alex

P.S: Hier sind die Dekoder auch noch etwas erklärt:
http://techreport.com/articles.x/14458/3
Es sollte auch auffallen dass alle andren Berichte, ausser der von Anand, nichts von "spekulativ" faseln ...
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh