Nachteile von x86? Vorteile von RISC, PowerPC, ...?

[G_ast]

Ich meine jetzt vom Assembler her. Soweit ich weiß, gibt es da 3 Typen: [c = a + b]
a) rein Stackbasiert: push a; push b; add; pop c;
b) Akkumulator: mov c, a; add c, b;
c) keine Ahnung: add a,b, c

x86 ist ja der Typ b). Haben die anderen Architekturen mehr Register? Sind sie einfacher/schwieriger für den Compiler? Einfacher/schwieriger für den Prozessorbauer?

Sonstiges?

[Stone2001]

Original geschrieben von G_ast
Ich meine jetzt vom Assembler her. Soweit ich weiß, gibt es da 3 Typen: [c = a + b]
a) rein Stackbasiert: push a; push b; add; pop c;
b) Akkumulator: mov c, a; add c, b;
c) keine Ahnung: add a,b, c

x86 ist ja der Typ b). Haben die anderen Architekturen mehr Register? Sind sie einfacher/schwieriger für den Compiler? Einfacher/schwieriger für den Prozessorbauer?

Sonstiges?
hmm, wenn ich mich jetzt recht erinnere, ist x86 vom Typ d.)
d.) add a, b : wobei das Ergebnis in a abgelegt wird.

RISC Prozessoren haben als Register-Register-Architekturen recht viele Register. CISC haben im Vergleich weniger.
Ich denke mal, das ein Compiler für eine CISC-Architektur schneller geschrieben ist, als für eine RISC-Maschiene, da mehr Befehle im Prozessor vorhanden sind (die muß man nicht erst effizient emulieren,...).
Was jetzt für den Prozessorbauer schwieriger ist, kann ich nur schwer schätzen, ich denke aber mal das RISC-Rechner aufwendiger sind, da z.b. die Pipeline bei vielen CISC-Rechner nicht existiert. Dagegen steht aber die aufwendige Dekodierlogik bei den CISCs!

[Coda]

RISC ist deutlich einfacher zu bauen, denn moderne x86 CPUs sind eigentlich RISC mit nem Dekoder vorne dran, die Logik kann bei reinem RISC entfallen.

[Gast]

RISC ist deutlich einfacher zu bauen, denn moderne x86 CPUs sind eigentlich RISC mit nem Dekoder vorne dran, die Logik kann bei reinem RISC entfallen.

Sowohl für die Verarbeitung der x86-Befehle nach der ursprünglichen CISC-Methode, als auch für die Umwandlung der x86-Befehle werden viele Ressourcen verschwendet, für x86-Translation tendenziell sogar mehr, als für die Verarbeitung über Mikroprogrammierung. Viele Millionen Transistoren sind damit beschäftigt, den Prozessor mit Windows kompatibel zu machen und verbrauchen Strom, ohne zur Rechenleistung beizutragen. Da die verfügbaren Ressourcen sich mit jeder Prozessor Generation vervielfachen, dachte man, man könnte diesen Overhead bald vernachlässigen. Heute aber wird mehr auf Stromsparen geachtet und Leistungssteigerungen bei Prozessoren werden nicht mehr durch Vergrößern eines einzelnen Prozessors und höhere Taktung erreicht, sondern durch Mehrprozessor-Technik. Mit der Vervielfachung kompletter Prozessorkerne steigt die Menge der von der x86-Übersetzungshardware verbrauchten Ressourcen nun doch wieder an.
Über die tatsächliche Menge der Transistoren, die für den x86-Overhead verbraucht werden, schweigen sich die Hersteller von x86-Prozessoren weitestgehend aus. Ein Pentium Pro, aus dem die aktuellen Core-Prozessoren entwickelt wurden, soll ca. 40% seiner Transistoren gebraucht haben, um x86-Befehle zu übersetzen. In heutigen x86-Prozessoren dürfte der x86-Overhead im Bereich von 10 Millionen Transistoren pro Prozessorkern liegen. (Diese Zahl entspricht etwa zwei bis drei kompletten ARM-Prozessorkernen, von denen einer im iPhone zum Einsatz kommt!)

http://www.addison-wesley.de/media_remote/katalog/bsp/9783827362360bsp.pdf

[Coda]

Mit der Vervielfachung kompletter Prozessorkerne steigt die Menge der von der x86-Übersetzungshardware verbrauchten Ressourcen nun doch wieder an.
Prozentual nicht.

Wir haben das Thema nun schon einige Male durchgekaut. Man darf die "Decodierungshardware" auch nicht schwarz/weiß nur x86 zuteilen. Auch andere Architekturen brauchen ab einem bestimmten Punkt Dekodierer für Out-Of-Order-Execution und Register Renaming um performant zu bleiben. Read-Write-Hazards kann auch die beste ISA nicht beseitigen.

ARMs sind primär so klein, weil sie auf Out-Of-Order-Execution und solche Dinge komplett verzichten. Aber ich verschwende meine Zeit.

[StefanV]

RISC vs CISC ist eine Diskussion aus der Computersteinzeit, diese Unterteilung gibt es bei 'modernen Prozessoren' kaum noch!

Es sind nur noch Befehlssätze...

[Gast]

ARMs sind primär so klein, weil sie auf Out-Of-Order-Execution und solche Dinge komplett verzichten. Aber ich verschwende meine Zeit.
Aber nicht der Cortex-A9?

RISC vs CISC ist eine Diskussion aus der Computersteinzeit, diese Unterteilung gibt es bei 'modernen Prozessoren' kaum noch!

Es sind nur noch Befehlssätze...
Gerade die Befehlssätze sind doch DIE Unterscheidung bzw. die Läge der Befehle…?

[(del)]

Gerade die Befehlssätze sind doch DIE Unterscheidung bzw. die Läge der Befehle…?Sagt er doch :|

Ich hab das mit den 40% außer in diesem... Buch nirgendwo finden können und hab nie was von gehört. Gibt es noch andere Quellen, außer in dieser PowerPC-Fanboyschmiere?

[Gast]

Gibt es noch andere Quellen

Ich konnte das hier finden:

The Cost of x86 Legacy Support on the P6
(S. 106 Inside the Machine: An Illustrated Introduction to Microprocessors and Computer Architecture von Jon Stokes: http://books.google.com/books?id=Q1zSIarI8xoC&pg=PA91&lpg=PA91&dq=pentium+pro+%2B+transistoren+%2B+x86+overhead&source=bl&ots=qp2FBNhQvm&sig=labqqBMN1EJQZk5WMXDnRCDc-fY&hl=de&ei=A4_uSuzTBpL__AbcjbWABw&sa=X&oi=book_result&ct=result&resnum=2&ved=0CAoQ6AEwAQ#v=onepage&q=&f=false )

All of this decoding and translation hardware takes up a lot of transistors. MDR estimates that close to 50 percent of the P6's transistors budget is spent on x86 legacy support. If correct, that's even higher that the astonishing 30 percent estimate for the original Pentium, and even if it's incorrect, it still suggests that the cost of legacy support is quite high.
…
…


The second decode stage isn't the only place where legacy x86 support added significant overhead to the Pentium design. According to an MPR article published at the time (see bibliography), Intel estimated that a whopping 30% of the Pentium's transistors were dedicated solely to providing x86 legacy support. When you consider the fact that the Pentium's RISC competitors with comparable transistor counts could spend those transistors on performance-enhancing hardware like execution units and cache, it's no wonder that the Pentium lagged behind.
A large chunk of the Pentium's legacy-supporting transistors were eaten up by the Pentium's microcode ROM. If you read my old RISC vs. CISC article, then you know that one of the big benefits of RISC processors was that they didn't need the microcode ROMs that CISC designs required for decoding large, complex instructions.
The front-end of the Pentium also suffered from x86-related bloat in that its prefetch logic had to take account of the fact that x86 instructions are not a uniform size and hence could straddle cache lines. The Pentium's decode logic also had to support x86's segmented memory model, which meant checking for and enforcing code segment limits; such checking required its own dedicated address calculation hardware, in addition to the Pentium's other dedicated address hardware. Furthermore, all of the Pentium's dedicated address hardware needed four input ports, which again spelled more transistors spent.
So to summarize, the Pentium's entire front-end was bloated and distended with hardware that was there solely to support x86 (mis)features which were rapidly falling out of use. With transistor budgets as tight as they were, each of those extra address adders and prefetch buffers — not to mention the microcode ROM — represented a painful expenditure of scarce resources that did nothing to enhance performance.
Fortunately for Intel, this wasn't the end of the story. There were a few facts and trends working in the favor of Intel and the x86 ISA. If we momentarily forget about ISA extensions like MMX, SSE, etc. and the odd handful of special-purpose instructions like CPUID that get added to the x86 ISA every so often, the core legacy x86 ISA is fixed in size and has not grown over the years; similarly, with one exception (the P6, covered below), the amount of hardware that it takes to support such instructions has not tended to grow either.
Transistors, on the other hand, have shrunk rapidly since the Pentium was introduced. When you put these two facts together, this means that the relative cost (in transistors) of x86 support, a cost that is mostly concentrated in an x86 CPU's front-end, has dropped as CPU transistor counts have increased.
Today, x86 support accounts for well under 10% of the transistors on the Pentium 4 — a drastic improvement over the original Pentium, and one that has contributed significantly to the ability of x86 hardware to catch up to and even surpass their RISC competitors in both integer and floating-point performance. In other words, Moore's Curves have been extremely kind to the x86 ISA.

http://www.mokslai.lt/referatai/referatas/about-cpu-puslapis1.html

There are a number of places, like the Pentium's-decode-2-stage, where legacy x86 support adds significant overhead to the Pentium's design. Intel has estimated that a whopping 30 percent of the Pentium's trasnistors are dedicated solely to providing x86 legacy support. When you consider the fact that the Pentium's RISC competitors with comparable transistors counts could spend those transistors on performance-enhancing hardware like execution units and cache, it's no wonder that the Pentium lagged behind some of its contemporaries when it was first introduced.
A large chunk of Pentium's legacy-supporting transistors are eaten up by its microcode ROM. Chapter 4 explained that ohne of the big benefits of RISC processors is that they don't need the microcode ROMs that CISC designs require for decoding large, complex instructions. (For more on x86 as a CISC ISA, see the section "CISC, RISC, and Instruction Set Translation" on page 103.)
The front end of the Pentium also suffers from x86-related bloat, in that its prefetch logic has to take count of the fact tat x86 instructions are not a uniform size and hence can straddle cache lines. The Pentium's decode logic also has to support x86's segmented memory model, which means checking for and enforcing code segement limits; such checking requires its own dedicated address calculation hardware, in addition to the Pentium's other address hardware.


http://books.google.com/books?id=Q1zSIarI8xoC&pg=PA91&dq=pentium+pro+%2B+transistoren+%2B+x86+overhead&hl=de#v=onepage&q=&f=false

Inside the Machine: An Illustrated Introduction to Microprocessors and Computer Architecture von Jon Stokes

[Gast]

All of this decoding and translation hardware takes up a lot of transistors. MDR estimates that close to 50 percent of the P6's transistors budget is spent on x86 legacy support. If correct, that's even higher that the astonishing 30 percent estimate for the original Pentium, and even if it's incorrect, it still suggests that the cost of legacy support is quite high.

40 percent.
http://books.google.com/books?ei=A4_uSuzTBpL__AbcjbWABw&ct=result&hl=de&id=Q1zSIarI8xoC&dq=pentium+pro+++transistoren+++x86+overhead&ots=qp2FBNhQvm&q=MDR+estimates#v=snippet&q=MDR%20estimates&f=false

[Exxtreme]

Der PPro ist Vergangenheit. Mag durchaus sein, daß die Dekoder-Logik soviel verschlungen hat. Aber einerseits sind die Dekoder auch besser geworden und und zweitens ist das auch nicht so, daß die Dekoder mit der Transistoranzahl linear mitwachsen. Der PPRo hatte 5,5 Mio. Transistoren. Wenn 40% davon auf die Dekoder-Logik entfielen dann waren es 2,2 Mio.

Der Phenom 2 hat jetzt schon 758 Mio. Transistoren (http://www.zdnet.de/arbeitsplatzrechner_peripherie_in_unternehmen_shanghai_fuer_den_desktop_amd_phen om_ii_im_test_story-20000002-39200907-1.htm). Davon geht wohl das meiste für den Cache drauf. Und wenn man jetzt die 2,2 Mio vervierfacht wegen 4 Kernen kommt man auf auf 8,8 Mio. Und das sind gerademal 1,2%. Ich weiss zwar, daß das eine Milchmädchenrechnung ist weil man nicht weiss wie groß die x86-Dekoder vom Phenom 2 sind. Ich denke aber nicht, daß diese Zahl großartig von den 1,2 % abweicht.

[(del)]

Und wenn man jetzt die 2,2 Mio vervierfacht wegen 4 Kernen kommt man auf auf 8,8 Mio. Und das sind gerademal 1,2%. Ich weiss zwar, daß das eine Milchmädchenrechnung istNö ist es nicht. Lassen wir das durch paar neue Klamotten und Tricks gar auf 1,5% anwachsen und mit HT der Vierkerne auf 2% (die Dekoder werden immer schon länger so ausgelegt, daß sie real schneller sind als die ALUs theoretisch sein könnten).

Ok. Das ist dann die Realität. Das ist der Tribut an die Kompatibilität über die wir alle uns einen riesigen Keks freuen.

Danke AMD, danke Intel. Und danke Microsoft, daß Win7 die allermeisten Programme die auf XP laufen problemlos ausführt.

[Gast]

Eigenschaften und Probleme der x86-ISA
http://www.addison-wesley.de/media_remote/katalog/bsp/9783827362360bsp.pdf
Fullquotes aus urheberrechtlich geschützten Medien sind nicht erlaubt!

[Crazy_Chris]

Das sind doch alles Sachen die schon 1000 mal hier im Forum durchgekaut wurden. SuFu! :freak:

[mrt]

Immer wieder die gleiche Diskussion.
Bei den beiden tollen Quellen wird vergessen, dass der P6 eine OOO-Architektur ist und daher zwingend ein passendes Frontend braucht. Das dieses ein paar Transistoren kostet sollte nicht verwundern. ;)
Zu den Zahlen die dem P5 angedichtet werden, sag ich nichts. Schwachsinn²
Das Ding verwendet nicht einmal einen RISC-Kern, der ist noch stark mit den "echten" x86ern verwandt...

Ein schneller RISC-Kern kommt um OOO-Ausführung, Registerumbennenung usw nicht herum -> braucht auch ein entsprechendes Frontend dafür ;)

x86-Kompatibilität gibts heute, von etwaigen Patenten abgesehen, für fast nichts.
Aber nicht der Cortex-A9?
Der hat 2 OOO-Stufen, also ja. Das Backend ist allerdings nicht so komplex als das es da ein fettes Frontend bräuchte. Davon abgesehen ist der A9 auch nicht gerade der kleinste seiner Gattung und wir werden ihn wohl erst mit 40nm in natura sehn.

[Gast]

Wikipedia sagt zumindest:
"Anders, als der Name es vermuten lässt, unterscheidet sich die Architektur des Pentium Pro deutlich von der des früheren Pentium-Prozessors. Der Pentium Pro enthielt einige wichtige neue Konzepte, wie einen RISC-Kern. Er war also kein reiner CISC-Prozessor mehr, sondern eher eine Art Hybrid. Außerdem wurde mit der „Out-of-order execution“ ein Konzept eingeführt, welches das Leistungspotenzial erhöhte. Während der Pentium Prozessorkern x86-Code nativ ausführt, enthält der Pentium Pro-Prozessorkern drei parallel arbeitende RISC Pipelines, die mittels dreier Decoder-Einheiten den zugrundeliegenden x86-Code in RISC-Befehle übersetzt. Dieser so prozessorintern modifizierte Programm-Code kann effizienter auf die Pipelines aufgeteilt werden, was eine bessere Parallelität der Befehlsabarbeitung ermöglicht. Kernstück des Pentium Pro ist der P6-Prozessorkern, der später in modifizierter Form dann im Pentium II, Pentium III, Pentium M und schließlich in der aktuellen Intel Core Architektur Verwendung findet. Die P6-Architektur, die den Grundstein für die 686er-Klassifikation legt, war der wichtigste Schritt in der Entwicklung von x86er Prozessoren seit der Einführung des 386ers als 32-Bit-CPU mit seiner MMU."

http://de.wikipedia.org/wiki/Pentium_Pro

Btw. zu dem zitiertem Buch kann man hier Kritik posten.
http://www.addison-wesley.de/main/main.asp?page=deutsch/bookdetails&productid=172156

[Gast]

Eigenschaften und Probleme der x86-ISA
http://www.addison-wesley.de/media_remote/katalog/bsp/9783827362360bsp.pdf
Fullquotes aus urheberrechtlich geschützten Medien sind nicht erlaubt!
Das stimmt doch überhaupt nicht?! Der Inhalt ist für jeden frei einsehbar und zudem wurde die Quellenangabe inkl. Link mitgeliefert.

[Exxtreme]

Das stimmt doch überhaupt nicht?! Der Inhalt ist für jeden frei einsehbar und zudem wurde die Quellenangabe inkl. Link mitgeliefert.
Ist völlig egal ob der Inhalt für jeden einsehbar ist. Die Forenregeln sind klar und deutlich formuliert.

http://www.forum-3dcenter.org/vbulletin/faq.php?faq=forum_faq#faq_forum_faq_rules


Aus urheberrechtlichen Gründen können wir Full-Quotes, also vollständig kopierte Artikel, von fremden Autoren ohne deren Einverständnis hier nicht veröffentlichen. Postings, die einen Artikel ganz oder im Übermaß per Copy&Paste (oder als Scan vom Heft/Buch) kopieren, laufen Gefahr, kommentarlos gekürzt oder gelöscht zu werden.
Kontextbezogene Zitate bzw. der sogenannte "Teaser" können natürlich im Posting erscheinen, sofern es dem Verständnis dient. In jedem Fall ist aber ein Link zum Originalartikel obligatorisch. Siehe hierzu auch den Wikipedia Artikel zum Zitat, insbesondere den Abschnitt über Klein- und Großzitate im Urheberrecht.

[mrt]

@Gast
P6 ist eine OOO-Architektur, bestreitet ja niemand, ich hab nur was zum P5 geschrieben...

Wenn der Text nicht unter einer entsprechenden Lizenz steht, darf man keine Fullqoutes machen, egal ob man ihn im Netz lesen kann.

[Gast]

ARMs sind primär so klein, weil sie auf Out-Of-Order-Execution und solche Dinge komplett verzichten. Aber ich verschwende meine Zeit.
Gilt nicht für einen A9.
Atom ist übrigens auch In-Order, trotzdem riesig im Vergleich zu einem ARM (inkl. A9).

[Coda]

Atom ist übrigens auch In-Order, trotzdem riesig im Vergleich zu einem ARM (inkl. A9).
Quelle? Auf dem Atom-Die ist gerade mal 28% (http://images.anandtech.com/reviews/cpu/intel/atom/deepdive/seaoffubs.jpg) der Fläche wirkliche x86-Logik, der Rest ist Cache und I/O. Und vollständig In-Order ist er auch nicht.

ARM bietet seine Designs primär als SOC an und da gibt es fast nie Die-Shots. Gibt es überhaupt schon A9 auf dem Markt?

So unbloatet ist das ARM-Instruction-Set nämlich auch nicht. Es gibt inzwischen 3 verschiedene Grundinstruction-Sets (ARM, Thumb, Thumb2), dazu VFP, Neon, Jazelle, Integer-SIMD, usw.

Dazu kommt, dass man Atom wohl als Einzel-CPU gar nicht viel kleiner hätte machen können ohne Pad-Limitiert zu sein. Warum sollte man dann um jeden Transistor im Core kämpfen? Das sind bei ARM ganz andere Designrichtlinien. Offenbar sind bei Atom auch alle Pipeline-Buffer als 8T-SRAM ausgeführt.

Es wäre mal interessant wie ein x86-Design von ARM aussehen würde ;)

[Gast]

Because a huge chunk of Silverthorne's die area is cache, the percentage of total die area that the new processor spends on x86 instruction decoding won't be as high as the original Pentium's 40 percent, but may well be in the double digits. Like the original Pentium, this relatively large number of transistors spent on x86 decode hardware will put Silverthorne at a performance and performance/watt disadvantage compared to a leaner RISC design like ARM, which can spend more die area on performance-enhancing cache. And Silverthorne's lower-cost Diamondville derivative, which will probably be underclocked and/or have less cache than its big brother, will look even worse next to a comparable ARM part.
http://arstechnica.com/gadgets/news/2007/12/return-of-the-son-of-pentium-in-2008-intels-new-ultramobile-processors.ars

Eric Schorn, Vice President der CPU-Marketingabteilung, brachte den Wettstreit mit Intel um Prozessoren für mobile Internet-taugliche Geräte im Gespräch mit heise online auf einen einfachen Nenner: Intel muss versuchen, die eigenen CPU-Kerne billiger und sparsamer zu machen, ARM hingegen eine Software-Infrastruktur schaffen. An dieser Front konnte ARM kürzlich einen Teilerfolg vermelden: Flash 10.1 soll auch auf ARM-CPUs laufen. Dennoch bleibt die Code-Basis x86-optimierter Software deutlich größer. Allerdings belegt allein der x86-Instruction-Decoder eines Atom so viel Chipfläche wie ein ganzer Cortex-A5.
http://www.heise.de/newsticker/meldung/ARM-Nachwuchs-fuer-die-die-Cortex-A-Familie-836348.html

Es wäre mal interessant wie ein x86-Design von ARM aussehen würde
Sinn?

[Coda]

Der Sinn ist das man einen wirklichen Vergleich hätte zwischen einem SOC-Design und einem ganzen Prozessor und auch entsprechend gleichen Designrichtlinien.

Versteh mich nicht falsch, mich würde auch mal brennend interessieren wieviel x86 wirklich kostet im Endeffekt - bei gleicher Performance.

[Acid-Beatz]

Is doch prinzipiell scheißegal ob CISC,RISC oder Heinzelmännchen mit ihren Taschenrechnern, wir sind sowieso an den Markt gebunden und ihm ausgeliefert ;)
x86 bringt eine mehr als befriedigende Leistung und wenn man bedenkt, dass ich damit immer noch Programme ausführen kann, die 20 Jahre und älter sind, so find ich das mehr als beachtlich ( ob ichs wirklich mache ist natürlich das andere aber was ich damit ausdrücken will, ist, dass man immer die Kompatibilität gewahrt hat )
Andere Ansätze mögen zwar auf den erste Blick schneller sein, aber das geht dann wieder auf Kosten von irgendwas anderem ( z.B die schwierige Programmierbarkeit von PS2 und PS3 )

x86 ist ein Allroundtalent und das wird sich so schnell auch nicht ändern, die x64 Implementierung hat den Weg für die nächsten Jahrzehnte geebnet ;)

[Gast]

the x86 instruction proprietary extensions: a waste of time, money and energy
http://www.anandtech.com/weblog/showpost.aspx?i=661

[Coda]

Da geht es doch nicht um x86 an sich sondern um den Instruction-Wildwuchs seitens der Hersteller.

Beim ARM-Instruction-Set blickt auch kein Mensch mehr durch.

[hell_bird]

könnte man nicht auch um einiges energieeffizienter werden, wenn man die ISA speziell auf das heutige Anwenderverhalten abstimmt? (Office, Browser, Multimedia) Wenn man einfach ein paar Betriebssystemfunktionen wie beispielsweise scheduling auf den Prozessor nimmt kann man doch nur gewinnen?

[BlackBirdSR]

Natürlich... niemand wird bestreiten, dass x86/x64 veraltet, aufgebläht und ineffizienter als andere Lösungen ist.

Aber über all dem steht die Kompatibilität und die Verbreitung von beinahe 100% Marktdurchdringung. Es gibt einfach auf dem Planeten Erde nur x86 für PCs. Das hat so viel Eigendynamik, dass
a) neue ISA-Extensions sind kaum auswirken.
b) ein ISA-Wechsel ein Ding der Unmöglichkeit ist.
c) selbst x64 muss seit Jahren kämpfen und kann nur schleichend Markt gewinnen, weil es absolut überfällig ist.

[Gast]

Gerade gefunden und scheint auf den ersten Blick zu stimmen.


Power7 : 45nm, 8 Cores, 4 Threads/Core, 32MB L3, 1.2 Milliarden
Transistoren
Nehalem: 45nm, 8 Cores, 2 Threads/Core, 16MB L3, 2.3 Milliarden
Transistoren

http://www.heise.de/open/news/foren/S-Re-Noch/forum-171454/msg-17838751/read/

Wie ist das zu erklären?

[AnarchX]

L3-Cache beim Power7 ist eDRAM. Und Beckton/Nehalem-EX hat 24MiB L3-Cach (http://www.computerbase.de/bildstrecke/25712/5/)e.
Aber bei der Die-Size sind Power7 und Beckton doch wieder ziemlich ähnlich.

[Gast]

Zum Beispiel durch den Einsatz von EDram- statt S-ramzellen und was man bei x86-Prozessoren als Core sieht und bei sonstigen Architekturen sind auch meistens zwei Paar Stiefel..

[Triskaine]

Power 7 braucht für seine 32MB L3 Cache in eDRAM Bauweise ~270 Millionen Transistoren.
Beckton braucht für seine 24MB L3 Cache in 6T-SRAM Bauweise ~1208 Millionen Transistoren.

Vergleicht man nun die Transistoren Anzahl ohne L3 Cache dann kommt man hier auf nahezu identische Werte um die 1 Milliarde Transistoren.
Einen großen Vorteil für Power sehe ich hier nicht. Übrigens, Power 7 wird einen Verbrauch von ca. 200 Watt haben und standardmäßig mit Wasserkühlung geliefert werden.

[Gast]

Quelle? Auf dem Atom-Die ist gerade mal 28% (http://images.anandtech.com/reviews/cpu/intel/atom/deepdive/seaoffubs.jpg) der Fläche wirkliche x86-Logik, der Rest ist Cache und I/O. Und vollständig In-Order ist er auch nicht.

Ich meine gelesen zu haben, dass ein Cortex A8 dagegen gerade mal um die 3 Millionen Transistoren benötigt.
Beim Atom sind es laut der obigen Quelle um die 13 bis 14 Millionen Transistoren.

[MountWalker]

@ Power-Architektur

Nicht nur die Cachebauweise, Power6 ist im gegensatz zu seinen Vorgängern eine In-Order-Architketur, es wäre also nicht ungewöhnlich, wenn Power7 auch wieder In-Order wird.

Ich find aber allgemein das Rechtfertigen von x86 einigermaßen albern - vor drei Jahren oder so wurde doch irgendwsoein Uraltprogramm (keine Ahnung, ich glaub es war wget oder sowas) von neuen programmierern übernommen und die stellten erstmal fest, dass der Code nach 15 jahren "Pflege" dermaßen zerfiremelt war, dass niemand mehr eine Chance hatte durchzusehen - genereller ratschlag war dann: "Nutz das Ding nicht mehr, bis wir es kom plett neugeschrieben haben" - also ich weiß nicht, aber sowas zeigt doch wie (un)wichtig diese Binärcoekompatibilität ist; man braucht sie so nötig wie einen Kropf.

Ist ja alles ganz toll, dass der Unterschied durch die variable Instruction-Länge marginal ist, aber man muss deswegen nicht X86 mit solchen unargumenten verteidigen. Bei dem was Anandtech kommentiert hatte, gehts even auch nicht nur um Wildwuchs, sondern auch darum, dass für 20 Jahre alten Code Instruction-Kompatibilität herrscht, obwohl man eh null komma keine Chance hat ein DOS3-Programm auf Windows XP ohne Dosemulator zum laufen zu bringen. Und um ein 20 Jahre altes Dosprogramm auf nem Core2 zu starten, kann ich mir dann auch mal eine Emulation der ISA leisten - fragt C64 Fans, die ihre C64-Kompilate von Turrican mit C64-Emulator auf Windows9x-Maschinen gezockt haben... (von Rosetta ganz zu schwiegen)

[RLZ]

@ Power-Architektur

Nicht nur die Cachebauweise, Power6 ist im gegensatz zu seinen Vorgängern eine In-Order-Architketur, es wäre also nicht ungewöhnlich, wenn Power7 auch wieder In-Order wird.
Das wäre verdammt ungewöhnlich, weil über den Power7 schon verdammt viel* (http://www.ibm.com/developerworks/wikis/download/attachments/104533501/POWER7%2B-%2BThe%2BBeat%2BGoes%2BOn.pdf) bekannt ist.

[IVN]

Gilt nicht für einen A9.
Atom ist übrigens auch In-Order, trotzdem riesig im Vergleich zu einem ARM (inkl. A9).
Und ist wahrscheinlich auch zig mal schneller als diese Schinken. Ich meine, es ist ja schön und gut, das der iPhone ne ARM-CPU hat, was sagt das aber über die Performance aus? Richtig: Nix!

Ein iPhone, und somit auch der ARM drin, wird nie mit solchen rechenintensiven Aufgaben konfrontiert werden, wie ein Atom-PC.

[Gast]

der ARM drin, wird nie mit solchen rechenintensiven Aufgaben konfrontiert werden, wie ein Atom-PC.
Wieso das?
z.B. Netzwerkgeräte, wie z.B. NAS
Künftige Netbooks auf ARM-Basis.


http://www.heise.de/bilder/145408/1/0
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7548227#post7548227

[IVN]

Wieso das?
z.B. Netzwerkgeräte, wie z.B. NAS
Künftige Netbooks auf ARM-Basis.


http://www.heise.de/bilder/145408/1/0
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7548227#post7548227

Ein NAS oder Netbook sind auch keine Wiederlegung meiner Aussage.

Ich hab z.B. auf nem €170 Nettop mit Atom 330 auch 40 Megapixel Fotos bearbeitet. Die waren im TIF, und ein bisschen mehr als 100MB groß. Und das Ergebnis war, der Atom kommt sogar mit solch einem Load zurecht. Er ist natürlich lahm i.V. mit ner modernen High-End-CPU, aber dafür sind Atom-Systeme auch dermassen günstig.

Ich würde zu sehr einen ARM sehen, wie er so ne Aufgabe meistert. ;)

[Gast]

Ich würde zu sehr einen ARM sehen, wie er so ne Aufgabe meistert. ;)
Das ist Spekulation.
http://www.heise.de/newsticker/meldung/ARM-Cortex-A9-Entweder-schnell-oder-sparsam-788960.html

Aber ein Cortex A9 (vor allem in der schnellen Ausführung, wenn er erhältlich ist) wird die Aufgabe wahrscheinlich besser bewerkstelligen, sofern es ordentliche Software gibt (bei deutlich weniger Stromvebrauch). Beim Atom hat es hingegen kaum Fortschritt in der Rechenleistung gegeben. Und beim Stromverbrauch sind es immer noch regelrechte Stromfresser, verglichen mit ARMs.

Aber:
Für so etwas ist weder ARM noch Atom die Zielgruppe.

[IVN]

Das ist Spekulation.
http://www.heise.de/newsticker/meldung/ARM-Cortex-A9-Entweder-schnell-oder-sparsam-788960.html

Aber ein Cortex A9 (vor allem in der schnellen Ausführung, wenn er erhältlich ist) wird die Aufgabe wahrscheinlich besser bewerkstelligen, sofern es ordentliche Software gibt (bei deutlich weniger Stromvebrauch).
Naja, das sind doch die typischen Marketing-Zahlen und -perfkürzel. XY Teraflops, DMIPS, Schrimps, dass ist eh immer das gleiche. Wahrscheinlich haben die da eine 100%ig Auslastung jeder erdenklichen Recheneinheit in der CPU angenomen und dann mit den MHz multipliziert...

Die Performance die ich bisher bei den iPhones beobachten konnte, spricht ehr gegen die These "ARMs sind besser als Atoms". Da dauert das aufbauen ner simplen Webseite eine gefühlte Ewigkeit. Wie soll dann eine solche, oder ähnliche CPU, schneller als ein Atom sein?

Beim Atom hat es hingegen kaum Fortschritt in der Rechenleistung gegeben. Und beim Stromverbrauch sind es immer noch regelrechte Stromfresser, verglichen mit ARMs.

Aber:
Für so etwas ist weder ARM noch Atom die Zielgruppe.

Tjo, dem Atom ist das nicht bewusst, während er in GIMP numberchruncht. ;)

Weil er nicht weiss, das er für sowas eigentlich zu lahm ist, performt er auch respektabel.

[Gast]

Da dauert das aufbauen ner simplen Webseite eine gefühlte Ewigkeit. Wie soll dann eine solche, oder ähnliche CPU, schneller als ein Atom sein?
Mit welchen iPhones denn?
Scherst du auch alle x86 CPUs über einen Kamm?
Zwischen dem 3GS und dem 3G liegen Welten. Das 3GS hat einen Cortex A8.
Ich habe hier einen iPod Touch 3G (ebenfalls Cortex A8 - evtl. noch höher getaktet als im 3GS ?) und im WLAN geht der Aufruf einer Web-Site sehr fix und ist teilweise kaum von einem richtigem Rechner zu unterscheiden.
Und das ist immer noch kein Cortex A9.


Weil er nicht weiss, das er eigentlich zu lahm für sowas ist, performt er auch respektabel.
Mit dem x-fachem Stromverbrauch...

[IVN]

Mit welchen iPhones denn?
Scherst du auch alle x86 CPUs über einen Kamm?
Zwischen dem 3GS und dem 3G liegen Welten. Das 3GS hat einen Cortex A8.
Ich habe hier einen iPod Touch 3G (ebenfalls Cortex A8 - evtl. noch höher getaktet als im 3GS ?) und im WLAN geht der Aufruf einer Web-Site sehr fix und ist teilweise kaum von einem richtigem Rechner zu unterscheiden.
Und das ist immer noch kein Cortex A9.

K.A. welches iPhone es nun genau war, für mich sehen die alle gleich aus.


Mit dem x-fachem Stromverbrauch...

Sei dir da nicht so sicher. Der a9 wird auch ganz schön viel Strom schlucken, wenn er erstmal in nem richtigem System sitzt. Richtiges MB, 1-2 GB RAM, ein IGP das "normale" LCDs befeuern kann und die nötigen Anschlüsse hat, eine Festplatte, Display...und last but not least, der a9 selbst, der für so ein Sys ordentlich hochgeprügelt wurde, mit mehr V und mehr MHz. Jo, erst dann wird man sehen können, ob der Verbrauch tatsächlich so niedrig ist.

[Gast]

K.A. welches iPhone es nun genau war, für mich sehen die alle gleich aus.
Klar sehen die alle gleich aus. Sind aber unterschiedlich schnell...


Sei dir da nicht so sicher. Der a9 wird auch ganz schön viel Strom schlucken, wenn er erstmal in nem richtigem System sitzt. Richtiges MB, 1-2 GB RAM, ein IGP das "normale" LCDs befeuern kann und die nötigen Anschlüsse hat, eine Festplatte, Display...und last but not least, der a9 selbst, der für so ein Sys ordentlich hochgeprügelt wurde, mit mehr V und mehr MHz. Jo, erst dann wird man sehen können, ob der Verbrauch tatsächlich so niedrig ist.
Ein iPhone 3GS (bzw. der iPod Touch 3G) mit seinem PowerVR SGX 535 sollte schon jetzt richtige Displays befeuern können ;)
AFAIK nutzt doch Intel selber diese GPU, bremst du nur durch mangelhafte Treiber aus.
Klar kommt dann noch Display (großer Stromverbraucher) usw. hinzu, so dass sich das wieder relativiert.