x86 greift um sich - Handy, TV, Roboter,...

[AnarchX]

Mit Intels erstem x86-SoC Canmore (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=429155) zielt man auf TV-Geräte und ähnliches ab, mit 32nm soll Atom den Sprung in die Mobilfunktelefone (http://www.xbitlabs.com/news/mobile/display/20080826105334_Intel_Atom_Based_Mobile_Phones_Due_in_2009__2010_Says_Company.htm l) machen und auch in der Robotik scheint man von den üblichen ARM-CPUs den Blick auf x86 zu schwenken (http://www.xbitlabs.com/news/other/display/20080827071744_Robots_Set_to_Use_x86_Microprocessors__Research_Firm.html).

Weiterhin sind ja Canmore/Atom inkl. Nachfolger prädestiniert für den Einsatz in allerlei Gerätschaften die kurz davor sind erweiterte Computing-Fähigkeiten zu erhalten, sei es die Vernetzung mit dem Heim-LAN oder eben die Aufwertung der Eingabemöglichkeiten inklusive Vereinfachung der Bedienung durch Einbringung einer gewissen Intelligenz und Erinnerungsvermögen.

Dann gibt es natürlich noch Larrabee, welcher x86 in den GPU-Markt und HPC-Co-Prozessoren bringen wird.

Wie seht ihr die Entwicklung: Wo sind für euch Vorteile von einem weit umspannenden Befehlssatz und wo die Nachteile?

[BlackBirdSR]

Wie seht ihr die Entwicklung: Wo sind für euch Vorteile von einem weit umspannenden Befehlssatz und wo die Nachteile?

In zwei Sätzen?

+ Unglaubliche Software- und Entwicklerbasis
+ nicht gerade optimale ISA, was durch extrem optimierte Kompiler inzwischen sowas von egal ist.

[MadManniMan]

Mal für weniger Bewanderte... was is hier ein Unterschied zwischen wem? Dass x86 ein Befehlssatz is, mit dem wir mit unseren Knechten ständig konfrontiert werden, war mir noch irgendwo klar, aber alles darüber hinaus raff ich grad nich.

[robbitop]

Da eine x86 CPU ja nur nach außen x86 ist, zahlt man für den ganzen Decoderkram drum herum schon einen nicht zu verachtenden Anteil an Transistoren, der keinen Nutzwert bringt. ARM kann bei gleicher Performance viel kleinere und sparsamere CPUs produzieren.
Der Vorteil ist lediglich die Softwarebasis vom PC.

Es ist nur die Frage, ob man auf Handheldgeräten, Industrierobotern u.Ä. auch PC-Software haben will. Ich persönlich favorisiere in diesem Bereich eher die ARM/MIPS SoCs.

[MadManniMan]

Also is das Zeug intern gar nich sooo unterschiedlich, je nach Ausführung?

[robbitop]

Naja die µArch zwischen MIPS / ARM / PPC und wie sie alle heißen differieren schon. Aber x86 ist halt intern kein x86 mehr, um Restriktionen aus dem wege zu gehen. Ich bin aber wahrlich kein CPU-Experte. BlackBirdSR kann da deutlich mehr dazu beitragen.

[Coda]

Also is das Zeug intern gar nich sooo unterschiedlich, je nach Ausführung?
Nach dem dekodieren kannst du praktisch jede Architekturidee auf x86, ARM, MIPS oder PowerPC gleichermaßen anwenden.

Details sind natürlich anders, weil sich auch die Semantik was man mit Instructions ausdrücken kann unterscheidet, vor allem was Interruptbehandlung, Anzahl der direkt verwendbaren Register, usw. betrifft.

[roidal]

Naja die µArch zwischen MIPS / ARM / PPC und wie sie alle heißen differieren schon. Aber x86 ist halt intern kein x86 mehr, um Restriktionen aus dem wege zu gehen. Ich bin aber wahrlich kein CPU-Experte. BlackBirdSR kann da deutlich mehr dazu beitragen.

Ist etwa ein PPC intern auch wirklich ein PPC? Ich denke dass dieser die Befehle auch in µOp's zerlegt.

[Coda]

Ja, jeder moderne PPC dekodiert.

[MadManniMan]

Also ist die generelle Leistungsfähigkeit auf jenen Architekturen grundsätzlich äquivalent?

[Trap]

Die nötigen Dekoder sind unterschiedlich aufwändig. Die Codedichte (Anzahl Instruktionsbytes für eine bestimmte Funktionalität) unterscheidet sich auch und damit die nötige Cachegröße.

x86 ist aufwändiger zu dekodieren, hat dafür aber etwas höhere Codedichte.

Je weniger der Chip kann, desto eher ist x86 ein Nachteil, da der Anteil des Dekoders am Chip dann entspreched groß ist. Bei aktuellen Desktop-Prozessoren ist der Dekoder nur ein winziger Anteil am Chip, deshalb kann man kaum etwas durch einfacher dekodierbare Instruktionen gewinnen.

[Tiamat]

Naja auch wenn ich an den Erfolg von X86 im typischen RISC Sektor nicht glaube, führt es dank Intel vielleicht dazu, dass die schlafenden Hunde (ARM und MIPS) aufgeweckt werden. Die fühlen sich bestimmt nicht zu unrecht auf die Füße getreten und werden wohl etwas gegen die Präsenz unternehmen(müssen) und ich würde es herzlich begrüßen, wenn ARM und MIPS plötzlich im Desktop-Sektor wildern würden.

[Exxtreme]

Naja auch wenn ich an den Erfolg von X86 im typischen RISC Sektor nicht glaube, führt es dank Intel vielleicht dazu, dass die schlafenden Hunde (ARM und MIPS) aufgeweckt werden. Die fühlen sich bestimmt nicht zu unrecht auf die Füße getreten und werden wohl etwas gegen die Präsenz unternehmen(müssen) und ich würde es herzlich begrüßen, wenn ARM und MIPS plötzlich im Desktop-Sektor wildern würden.
Der Desktop-Markt ist viel zu stark im Griff von x86.

[BlackBirdSR]

Der Desktop-Markt ist viel zu stark im Griff von x86.

Ich wage sogar zu behaupten, dass nicht mal Intel x64 (wirtschaftlich) abschaffen könnten. Selbst wenn sie wollten.

[Tiamat]

Ich denke das ist alles ne Sache des Angebots.
Es gab da vor kurzem 2 Netbooks mit MIPS64 CPU.
Das eine war aufgrund der dürftigen Austattung kein Erfolg und das andere wird erst noch zeigen müssen, ob es ein Erfolg wird. Da Emtec weder auf SSD , noch auf HD setzt, sondern auf eine seltsame Eigenkonstruktion, sehe ich das Book auf wieder sehr schnell vom Markt verschwinden.
Dennoch Ubuntu wurde portiert und es gibt ja auch andere Linux-Distris, die auf Mips laufen.
Nur abgesehen von diesen 2 Ausnahmen kenne ich keinen kommerziellen PCs, den ich im Laden erwerben kann, bei dem eine Mips CPU eingebaut ist.
Wenn die mal auf breiter Front kämen, würde es auch Käufer dafür geben, ganz klar.
So käme wenigstens mal ein Stein ins Rollen.

[Gast]

Es ist mit PowerPC mal ein Stein ins Rollen gekommen, der wieder fast zum stehen gekommen ist. Hat es etwas geändert? Und PowerPC war als Desktop-CPU bestimmt besser als ARM oder MIPS.

Spätestens seitdem Apple weg von PowerPC ist, glaube ich auch nicht mehr an eine echte Chance einer alternativen Architektur im Desktop-Segment, abgesehen von ganz kleinen Nischen vielleicht. Die müsste schon enorm besser sein.

[Tiamat]

PPC war ja auch Apple-exlusive, abgesehen von den Amiga-Bastlern und Mac-Aufrüstern..
HP,Fujitsu und Co haben auf jeden Fall keine PCs im Angebot gehabt.

[Gast]

PPC war ja auch Apple-exlusive, abgesehen von den Amiga-Bastlern und Mac-Aufrüstern..
HP,Fujitsu und Co haben auf jeden Fall keine PCs im Angebot gehabt.
PPC ist weniger exklusiv als x86. Kann jeder Ordern und sogar CPU nach Maß fertigen lassen. Du vergisst ausserdem die Workstation-Hersteller. Hier bekommst du noch ein System: http://www.terrasoftsolutions.com/news/2008/2008-07-23.shtml

Nach deiner Argumentation ist MIPS und ARM aber Mega-Exklusiv? Welche Hersteller?

[Tiamat]

Nein über die Workstation Position war ich mir bewusst, doch hier geht´s doch um Consumer-Hardware bzw zukünftige Consumerhardware.
Handy,TV,Receiver,Roboter.

>>nach deiner Argumentation ist MIPS und ARM aber Mega-Exklusiv? Welche Hersteller?<<
Na eben nicht, ich wollte doch damit zeigen, dass MIPS und ARM hier auf dem freien Markt positioniert sind.

Welche Hersteller? keine Ahnung, Texas Instrument hat doch jetzt grad ne neue Reihe von ARM Cortex CPUs herausgebracht, so einer würde dem Atom mehr als genug paroli bieten können.
Oder der Loongson Prozessor, den STM produziert und gerade am Anfang seiner Evolution steht, kam bereits in 2 Netbooks zum Einsatz. Gefertigt in 90nm verbraucht dieser bei 1Ghz 1-4Watt und verfügt für ein CPU-Startup über eine gute Performance.
Tegra von Nvidia, über den Rest kann man nur spekulieren.
Die Netbooks mit Linux verkaufen sich auch net schlecht, also wieso sollte dies mit ARM oder Mips anders sein.

[Gast]

Und was hat das jetzt mit PowerPC = Exklusiv zu tun? Es gibt auch den P.A. Semi (PowerPC) der in Netbooks _alle_ CPUs zum Frühstück verspeisen würde, bei vermutlich niedrigerer Leistungsaufnahme als das derzeitige Atom-Gepann. Wird aktuell vom US Militär eingesetzt.

Eine Lizenz bekommt so ziemlich jeder der möchte für PowerPC: http://www-03.ibm.com/technology/power/licensing/

[Coda]

Und was hat das jetzt mit PowerPC = Exklusiv zu tun? Es gibt auch den P.A. Semi (PowerPC) der in Netbooks _alle_ CPUs zum Frühstück verspeisen würde, bei vermutlich niedrigerer Leistungsaufnahme als das derzeitige Atom-Gepann.
Worauf basiert diese Behauptung eigentlich immer wieder? Ich habe noch keinerlei Benchmarks in diese Richtung gesehen.

Ich kann mir nicht vorstellen dass irgendeine CPU derzeit an die IPC von Penryn/Nehalem rankommt in diesem Segment.

[Gast]

Die meisten Seiten, auf denen es Hinweise gibt sind down, wie z.B. http://www.pt.com/products/prod_amc141.html :( Liegt wohl daran, dass AFAIK Apple nach dem Aufkauf von P.A. Semi nur noch das US Militär beliefert? Oder werden noch andere beliefert?
Man beachte, was alles in der CPU integriert ist... und es waren AFAIK auch "light" Varianten geplant.

Effizienz-Meister

Der effizienteste Hochleistungsprozessor der Welt ist jedoch nach den Darlegungen von P. A. Semi ihr PowerPC PA6T-1682M, begnüge er sich doch bei 2 GHz Taktfrequenz mit maximal 25 Watt Leistungsaufnahme. Und im typischen Betrieb soll der Energiebedarf nur zwischen 5 und 13 Watt liegen. Zum Vergleich: Laut Intel brauchen die Low-Voltage-(LV-)Versionen des Mobilprozessors Core 2 Duo mit 4 MByte L2-Cache lediglich 17 Watt Thermal Design Power (TDP), erreichen aber höchstens 1,5 GHz (Core 2 Duo L7400). Der PA6T mit zwei 64-bittigen PowerPC-Kernen und einem gemeinsamen L2-Cache von 2 MByte belegt bei Fertigung in 65-Nanometer-Technik 115 Quadratmillimeter Siliziumfläche. Mit rund 23 000 „Clock Gates“ machen die PA-Entwickler intensiv vom Clock-Gating Gebrauch, weit mehr als IBM bei Power6. Jeder Kern, die Cache-Arrays sowie die Controller für Speicher und I/O haben jeweils separate Spannungsversorgungen. Mit dieser feinkörnigen - und auch aufwendigen - Takt- und Spannungssteuerung quetscht P. A. Semi pro Watt die doppelte MIPS-Leistung eines Power6 aus ihrem Chip.

Laut P. A. Semi interessieren sich bereits 100 Firmen für den PWRficient PA6T-1682M. Er ist vor allem für Embedded-Systeme gedacht: Das integrierte I/O-Subsystem steuert acht PCI-Express-Ports an und enthält zwei 10-Gigabit-Ethernet- und vier Gigabit-Ethernet-Controller. Für 8500 US-Dollar offeriert P. A. Semi ein Development Kit mit einem PA6T-1682M, ein Muster des Prozessors selbst soll 700 US-Dollar kosten.
http://www.heise.de/ct/07/06/056/

[Coda]

Laut PASemi-Slide erreicht ein PWRefficient bei 2Ghz ">1000" SpecINT 2000. Intel liegt bei 2,133Ghz bei >2000 mit Conroe (nein SpecINT 2000 ist nicht multithreaded).

Das sind selbst wenn man Intels Compiler wegrechnet Welten.

[Gast]

Laut PASemi-Slide erreicht ein PWRefficient bei 2Ghz ">1000" SpecINT 2000. Intel liegt bei 2,133Ghz bei >2000 mit Conroe.

Das sind selbst wenn man Intels Compiler wegrechnet Welten.
Ich habe von Atom & Co gesprochen, dass er die wegfegen würde, dicht die großen Intels. ;)

[Gast]

Laut PASemi-Slide erreicht ein PWRefficient bei 2Ghz ">1000" SpecINT 2000. Intel liegt bei 2,133Ghz bei >2000 mit Conroe (nein SpecINT 2000 ist nicht multithreaded).

Das sind selbst wenn man Intels Compiler wegrechnet Welten.


Pro Kern, wenn das hier stimmt:

"Bei 2 GHz Taktfrequenz erreicht jeder Kern eine Performance von 1000 SPECint2000 und 1500 SPECfp2000. Bei der Ermittlung dieser Benchmarks verbraucht jeder der beiden CPU-Kerne etwa 4 Watt und erreicht damit eine Effizienz von 375 SPECint/W, liegt so mit um ein Vielfaches besser als ein Core-2 Duoprozessor."

Seite 7: http://www.topas.de/tt/2008_01/news_feb08.pdf

[Coda]

Der Transistorcount sollte ja auch deutlich höher sein. Ein ULV-Merom (65nm!) bei 1Ghz hat auch nur eine TDP von ~10W, also effektiv braucht das Ding <5W pro Core.

PWRefficient braucht immerhin 100 Mio. Transistoren pro Core. Atom nur ~50 Mio. Ich glaub das mit dem "wegfeegen" einfach nicht. Er würde wohl effizienter sein, aber nicht so maßgeblich dass sich da irgendwas bewegen würde.

Pro Kern, wenn das hier stimmt:

"Bei 2 GHz Taktfrequenz erreicht jeder Kern eine Performance von 1000 SPECint2000 und 1500 SPECfp2000. Bei der Ermittlung dieser Benchmarks verbraucht jeder der beiden CPU-Kerne etwa 4 Watt und erreicht damit eine Effizienz von 375 SPECint/W, liegt so mit um ein Vielfaches besser als ein Core-2 Duoprozessor."
Ja. Und Intel schafft pro Kern 2000 bei 2Ghz. SpecINT ist nicht multithreaded.

[Trap]

1000 SpecInt schafft auch der ULV Core 2 Duo noch locker und der hat 10 W TDP für beide Kerne zusammen. Bei angenommenen 5W und 1350 SpecInt sind das auch 270 SpecInt/W. "Ein vielfaches besser" stimmt da nicht so ganz.

Wie kommt man eigentlich mit 4W und 1000 SpecInt auf 375 SpecInt/W?

[Tiamat]

Das erinnert mich hier ein wenig an Flaschenpost ;D

@gast : Ich sagte, dass zu Zeiten von Apple-PPC der G5 Apple-exklusiv war. Das den inzwischen jeder lizensieren kann, ok. Aber ich bezweifle, dass dem so war, als er grad Apple´s High-end CPU war.
Desweiteren hast du mit dem PPC-Kapitel angefangen und nicht ich =)

Naja solche Vergleiche sind auch net so einfach. Es muss ja erstmal die gleiche Software auf beiden Plattformen laufen und daran scheitert´s schon meistens.

Dann sieht das typische Risc-Umfeld auch ein wenig anders aus.
Der Prozessor wird in ein Device eingebaut, dessen Lebenszeit vorher meist schon feststeht. Wird das Device aktualisiert, kommt meist ein anderer (neuerer)RISC-Prozessor zum Einsatz, der zum alten nicht kompatibel ist.
siehe Handys, Konsolen e.t.c

Bei x86 ist es immer eine straighte Linie, die zu alten Geräten kompatibel ist. Die Plattform profitiert von jahrelanger Optimierung auf die X86-Kompatiblen.

Demletzt hab ich grad irgendwo gelesen, dass TI für den OMAP einen neuen Compiler veröffentlicht hat, bei dem die Performance ca. um den Faktor 2 verbessert wurde. Natürlich könnten auch RISC-Hersteller ihre CPUs bis zum geht nicht mehr optimieren, aber meisten entscheidet einfach die Lebenszeit des Gerätes darüber.

Gäbe es auch eine straighte RISC-Line, wäre das ganze vergleichbarer.

Auch nicht zu verachten : Intel ist Technologiehersteller und Produzent in einem. MIPS und ARM sind nur die Technologiehersteller, die den Core fertigen, herstellen tut dies jeder x-beliebige Interessent und so gibt es auch dieses X86 Referenzdesign nicht, weil es hier schon mal mehr oder weniger abweichen kann, bzw. auf die eigenen Bedürfnisse angepasst ist.
All diese Faktoren gestalten einen Vergleich immer schwierig.

[Gast]

PWRefficient braucht immerhin 100 Mio. Transistoren pro Core. Atom nur ~50 Mio. Ich glaub das mit dem "wegfeegen" einfach nicht. Er würde wohl effizienter sein, aber nicht so maßgeblich dass sich da irgendwas bewegen würde.

21M transistors per core
http://www.power.org/devcon/07/Session_Downloads/PADC07_Hayter_PADC_FINALv3-jcc.pdf

Du musst auch die 2x10Gbit Lan, PCi-Express-Ports, ... rausrechnen...

[Coda]

Das ist dann aber auch ohne Cache. Der macht mindestens 100 Mio. Transistoren aus, wenn nicht mehr. Die Packdichte ist weitaus höher bei SRAM als bei der Logik.

Vor allem aber steht in dem Slide was von Max 25W bei 2Ghz. Wo ist das noch besonders "PWRefficient"?

[Tiamat]

Die 25W Max gelten allerdings mit diesem Minimainboard. Desweiteren macht das Teil aus Intel´s Atom Hackfleisch ;D
Und ist noch in 65nm gefertigt..

[Gast]

Der P.A. Semi PA6T-1682M ist ein 64-bit Der P.A. Semi PA6T-1682M ist ein 64-bit auf neu entwickelt wurde. Der 1682M-Chip integriert in einem so genanntem „Plattform-Prozessor“ ein System, welches üblicherweise aus drei bis fünf Chips besteht. Die gesamte Leistungsaufnahme beträgt 5-13 Watt (typisch) mit einem Maximum von 25 Watt, wobei beide CPUs mit 2 GHz getaktet werden. Dies ist eine drei- bis viermal geringere Leistungsaufnahme als die anderer Prozessorlösungen in 65-Nanometer-Technologie mit vergleichbarer Peripherie.
Bei 2 GHz Taktfrequenz erreicht jeder Kern eine Performance von 1000 SPECint2000 und 1500 SPECfp2000. Bei der Ermittlung dieser Benchmarks verbraucht jeder der beiden CPU-Kerne etwa 4 Watt und erreicht damit eine Ef zienz von 375 SPECint/W, liegt so mit um ein Vielfaches besser als ein Core-2 Duoprozessor.
Der 1682M besteht aus zwei 2 GHz Prozessoren (jeder mit einer Dual-Integer, Floating-Point und VMX Vektor-Einheit), 2 MB Level-2 Cache, zwei DDR-2 Memory-Controllern, sowie Hardware-Unterstützung für TCP/IP-Beschleunigung, Kryptographie, CRC-Prüfsummen und XOR-Berechnung. Der Chip integriert ein exibles I/O-Subsystem mit acht PCI-Express Controllern, zwei 10-Gigabit Ethernet-Controllern und vier Gigabit Ethernet-Controllern, welche sich 24 konfigurierbare SERDES-Lanes teilen. Die PWRfcient-Prozessoren erledigen damit viele Funktionen, die üblicherweise in zusätzlichen Chips abgewickelt werden müssen. Integriert wurden neben den Kernen auch Speicher, die South-Bridge (IOCH) und I/O-Schnittstellen.
Die Entwickler versprechen eine hohe Skalierbarkeit der modular aufgebauten Chips. Die Zahl der Kerne, Speicher-Controller, Protokolle und die Cache-Größe sollen sich leicht steigern lassen. So will P.A. Semi mit
einer ganzen Familie von Prozessoren verschiedene Anwendungsbereiche abdecken.
Trotz dieser umfangreichen Peripherie innerhalb des Chips ist sein Leis-
tungsverbrauch sensationell niedrig. Unter ungünstigsten Betriebsbedingungen werden 25 Watt umgesetzt, unter nor malen Konditionen begnügt sich der Baustein aber mit etwa 14 Watt. Maßnahmen, die zu diesen erstaunlich geringen Werten beitragen, sind u.a.:
...
...
...
http://www.topas.de/tt/2008_01/news_feb08.pdf

[Coda]

Die 25W Max gelten allerdings mit diesem Minimainboard. Desweiteren macht das Teil aus Intel´s Atom Hackfleisch ;D
Und ist noch in 65nm gefertigt..
Man sollte das Ding auch eher mit Vias Nano vergleichen als mit Intels Atom. Immerhin ist PWRficient ein Out-Of-Order-Design.

Atom ist auf eine sehr billige Produktion optimiert worden. Der Core ist deutlich kleiner.

[Gast]

Der Desktop-Markt ist viel zu stark im Griff von x86.
Kann man doch so wie bei Transmeta lösen?Oder bei bei der chinesischen Godson-Cpu.

[Tiamat]

Könnte man tun, jedoch würde dies zu einem erhöhten Stromverbrauch führen.
Die Godson CPU verbraucht in Version 3 dank x86 Decoder auch ihre 20 Watt.
Vorher nur 1-4W, das ist schon ein enormer Unterschied.

Hier habe ich was gefunden, was mal wieder zeigt, wie rückständig x86 ist.
Die Ps3 und Gpus wischen mit x86 jedenfalls den Boden auf ;D
http://www.computerbase.de/news/allgemein/forschung/2008/september/nvidia_kraft_foldinghome/

[Gast]

Hier habe ich was gefunden, was mal wieder zeigt, wie rückständig x86 ist.

Zeigt es nicht, denn es sind Spezialfälle, wo Cell und GPU sich so richtig austoben können.

[BlackBirdSR]

Hier habe ich was gefunden, was mal wieder zeigt, wie rückständig x86 ist.
Die Ps3 und Gpus wischen mit x86 jedenfalls den Boden auf ;D


Warum ist eine CPU Rückständig, wenn sie nicht in der Lage ist große Mengen an Gleitkomma-Operationen parallel auszuführen? Das ist im normalen Operationsschema einer CPU nicht vorgesehen. Und weder Itanium noch PowerPC noch x86 werden hier einem Vektorrechner Konkurrenz machen.

Ich könnte ja auch sagen wie Rückständig GPUs sind, weil sie nicht in der Lage sind SuperPi 1M in 12 Sekunden zu berechnen oder meinen Browser zu berechnen.

[Tiamat]

Ok ne GPU vielleicht nicht, aber die PS3 kann das sehr wohl.

[BlackBirdSR]

Ok ne GPU vielleicht nicht, aber die PS3 kann das sehr wohl.

Und warum?
Weil die PS3 eine General Purpose InOrder PowerPC-CPU besitzt, die zwar relativ langsam ist, aber genau das gleiche kann wie ein x64.
Die restlichen Einheiten im PS3-Cell sind Vektoreinheiten. Vom prinzip also das was eine GPU oder Larrabee auch sind.

Das Argument ist IMO einfach falsch. x64 (stat x86) ist nicht Rückständig. Tatsächlich sitzen in aktuellen CPUs von AMD und Intel mit die fortschrittlichsten Technologien die man im Bereich Computing bekommen kann. Das ändert klar nichts daran, dass die ISA vielleicht doof ist, und die Kompatibilität zum 386 ein bockiger Esel - richtig!.

Es ist doch so: Bei CPUs und GPUs handelt es sich um zwei unterschiedliche Ansätze für zwei unterschiedliche Probleme, die langsam konvergieren. Deswegen ist doch keiner Rückständig.

[Tiamat]

Natürlich sind die CPUs von Intel und AMD sehr fortschrittlich, keine Frage.
Und die wären noch viel besser, wenn man endlich mal alte Zöpfe abschneidet.
Darum ging es mir ja letztlich.
Dann hätten wir vielleicht jetzt stromsparendere CPUs mit 32,64 oder gar 128 Registern. Es ist vermessen zu glauben, dass sich dies in der gesamten 64bit Ära nicht nachteilig auswirken wird. Naja warten wir´s ab, denen wird noch früh genug der Arsch auf Grundeis gehen ;)

[BlackBirdSR]

Natürlich sind die CPUs von Intel und AMD sehr fortschrittlich, keine Frage.
Und die wären noch viel besser, wenn man endlich mal alte Zöpfe abschneidet.
Darum ging es mir ja letztlich.
Dann hätten wir vielleicht jetzt stromsparendere CPUs mit 32,64 oder gar 128 Registern. Es ist vermessen zu glauben, dass sich dies in der gesamten 64bit Ära nicht nachteilig auswirken wird. Naja warten wir´s ab, denen wird noch früh genug der Arsch auf Grundeis gehen ;)

Wie schon gesagt: Die Kompabilität ist sicherlich ein Nachteil.
Warum ist x86 aber wohl so erfolgreich? Eben wegen jenem Nachteil der zum größten Vorteil wird. Keine andere CPU hat es je geschafft erfolgreich gegen AMD und Intels x86/x64 zu wildern. Eben darum.
Alte Zöpfe abzuschneiden hieße diesen Vorteil zu verlieren. Und gerade dieser Vorteil erlaubt z.B Atom Larrabee Nano oder CPUs für Handies Roboter etc überhaupt zu exisiteren. Ansonsten würde die Dinger doch keiner so recht wollen. So sind sie plötzlich extrem interessant, bekommt man doch eine gigantische User/Software-Base gleich mit.

Was die Register betrifft: AMD hat deren sichtbare Anzahl bereits für x64 verdoppelt (GPR und SSE2+). Selbst dieser Schritt brachte aber weit weit weniger als eine Verdopplung der Performance. Wie alle anderen OOOe-Architekturen nutzten auch x86/x64-CPUs Register-Renaming. Es gibt massig Register die genutzt werden können. Der Kompiler sieht eben nur 16. Bei einer durschnittlichen IPC von 1.2 Ops/cycle ist das IMO auch ok ;)

Wo sich wirklich etwas tut, bei SIMD-Berechnungen wird auch massiv ausgebaut. Ob das nun SSE5, AVX oder Larrabee sind.

So schlimm ist x64 nun einfach nicht.

[Tiamat]

Zu den Registern: Ich schätze, dass dies einen anderen Grund hat.
X86 musste ja bis AMD64 mit 8 Registern auskommen. Die werden dann wohl dann das CPU-Design schon früher so ausgelegt haben, dass sich dieses Manko durch andere Techniken ausgleichen lässt. Vielleicht profitieren deswegen die Intel/AMD 64bitter nicht so sehr von den 8 zusätzlichen, keine Ahnung ehrlich gesagt.
Mein Wissen in diesem Bereich ist auch zu rudimentär, um das tiefgründiger analysieren zu können.

Mich würde wirklich mal interessieren wieviel Strom die x86 Dekoder ziehen,
wieviel Performance für das Dekodieren drauf geht und wieviel Strom man allein dadurch einsparen könnte, indem man auf 32bit Kompatiblität verzichten würde, immerhin sind ja jetzt 2 vollständige Dekodiereinheiten drauf.
Oder wie schlägt sich eine x86 CPU ohne x86 Unit im typischen relativ unoptimierten RISC-Umfeld. Aber über solche Sachen wird man wohl nur spekulieren können, da is würde, wäre und hätte angesagt ;D

[BlackBirdSR]

Zu den Registern: Ich schätze, dass dies einen anderen Grund hat.
X86 musste ja bis AMD64 mit 8 Registern auskommen. Die werden dann wohl dann das CPU-Design schon früher so ausgelegt haben, dass sich dieses Manko durch andere Techniken ausgleichen lässt. Vielleicht profitieren deswegen die Intel/AMD 64bitter nicht so sehr von den 8 zusätzlichen, keine Ahnung ehrlich gesagt.
Mein Wissen in diesem Bereich ist auch zu rudimentär, um das tiefgründiger analysieren zu können.


Wie gesagt: Die CPUs betreiben Register-Renaming. Dementsprechend haben sie bereits sehr große Registerfiles. Es bestand also nicht plötzlich ein kritischer Engpass, weil nur 6 Register für Daten zur Verfügung standen und die CPU sonst still steht.
Ist doch ganz einfach, warum die x64er nicht so profitieren: Abnehmender Grenzertrag. Es muss weniger Renaming statt finden, das war aber schon so hoch optimiert, dass es nicht so viel Performance kostet. Zudem laufen die meisten Registeroperationen inziwschen extrem schnell ab. Kein Vergleich zum 386 ;) Hätte es damals nur 8 Register gegeben, würden 16 sicherlich viel mehr Performance bringen. Und natürlich ist das ganze eine Frage der Wirtschaftlichkeit.


Mich würde wirklich mal interessieren wieviel Strom die x86 Dekoder ziehen,
wieviel Performance für das Dekodieren drauf geht und wieviel Strom man allein dadurch einsparen könnte, indem man auf 32bit Kompatiblität verzichten würde, immerhin sind ja jetzt 2 vollständige Dekodiereinheiten drauf.
Oder wie schlägt sich eine x86 CPU ohne x86 Unit im typischen relativ unoptimierten RISC-Umfeld. Aber über solche Sachen wird man wohl nur spekulieren können, da is würde, wäre und hätte angesagt ;D

Hä?
Es gibt keine x86 oder x64-Dekoder. Das ist ein physischer Block und fertig. Ohne x86-Kompatibilität fallen einige besondere Anweisungen weg und ein paar kleinere Sachen, aber das wars auch schon. Das ist ja das elegante daran: Es muss nichts emuliert oder dupliziert werden um x86-Kompatibilität zu behalten. Wieviel Strom die Decoder und Decoding-Stages brauchen ist unbekannt. Es wird schon ein wenig sein, ansonsten hätte man beim P4 nicht versucht eine Lösung dafür zu finden. Auf der anderen Seite: komplexe RISC-CPUs (was für ein beschissener Begriff ;)) sind auch nicht gerade genügsam was das betrifft. Schau dir nur mal Power(PC) an. Da gibt es auch ordentlich zu tun. Das ist nötig um später die IPC hoch zu halten.

Unoptimiertes RISC-Umfeld, was ist das? x86/x64 High Language-Code ginge wohl eher in diese Richtung. Am anderen Ende (dem Compiler) ist dann überall alles bis zum Maximum hin optimiert.

[SavageX]

Es gibt keine x86 oder x64-Dekoder.

Laut c't hat der C7 noch einen (von aussen ansprechbaren!) alternativen Befehlssatz, der ziemlich MIPS-artig sein soll ;-)

edit: Der C7 übersetzt die x86-Befehle intern in diesen alternativen Befehlssatz (wie es praktisch alle modernen x86-Prozessoren tun). Nur ist beim C7 dieser interne Befehlssatz auch von aussen nutzbar (macht nur keiner).

[Coda]

Dann hätten wir vielleicht jetzt stromsparendere CPUs mit 32,64 oder gar 128 Registern.
AMD hat mehr als 16 Register evaluiert für x86-64. Es lohnt sich einfach nicht. x86-CPUs haben intern sowieso genug Rename-Register und 16 Register sind einen Inner-Loop in aller Regel ausreichend.

[PHuV]

Was ich bei Intel nicht mag, ist der Little-Endian-Kram, ständig muß man auf diesen Mist aufpassen, wenn man auf Binärebene arbeitet. Natürlich macht es jetzt nicht den großen Unterschied, aber ich mag BE einfach lieber.

[Coda]

Könnte man tun, jedoch würde dies zu einem erhöhten Stromverbrauch führen.
Die Godson CPU verbraucht in Version 3 dank x86 Decoder auch ihre 20 Watt.
Vorher nur 1-4W, das ist schon ein enormer Unterschied.
Godson hat keinen x86-Decoder. Es wird in Software ausgeführt.

Hier habe ich was gefunden, was mal wieder zeigt, wie rückständig x86 ist.
Die Ps3 und Gpus wischen mit x86 jedenfalls den Boden auf ;D
http://www.computerbase.de/news/allgemein/forschung/2008/september/nvidia_kraft_foldinghome/
Äpfel und Birnen. Aber sowas von.

Was ich bei Intel nicht mag, ist der Little-Endian-Kram, ständig muß man auf diesen Mist aufpassen, wenn man auf Binärebene arbeitet. Natürlich macht es jetzt nicht den großen Unterschied, aber ich mag BE einfach lieber.
Little Endian hat auch seine Vorteile.

[Tiamat]

Hi,
Godson3 CPU vorgestellt. (http://winfuture.de/news,41841.html)

Beide Godson-3-Chips werden demnach im 65-Nanometer-Design gefertigt und verfügen über eine Taktfrequenz von 1 Gigahertz.
Bei den Chips handelt es sich den Angaben zufolge um skalierbare Designs mit konfigurierbaren Kernen und Cache-Speichern. Die Chips wurden außerdem sehr stromsparend konzipiert. So zieht die vierkernige CPU nur 10 Watt, das Modell mit acht Kernen 20 Watt.Als Ziel wurde definiert, mit den Godson-3-CPUs bis zum Jahr 2010 einen Supercomputer mit 1 Petaflops Leistung bauen zu können.

Das finde ich schon beeindruckend. Immerhin sind das keine Globalplayer wie Intel und AMD, noch irgendwelche CPU-Produzenten, sondern irgendein universitärer Lehrstuhl für technische Informatik, der Hammer.
Auch die Benchmarks bin ich sehr gespannt.

[Coda]

Via hat Nano auch mit einem Team von <40 Leuten entwickelt. Und das Ding zerlegt Godson.

Ob es schwer ist eine CPU zu entwickeln kommt vor allem darauf an welche Designparameter man wählt. Ein einfacher In-Order-Core ist um Längen einfacher als eine superskalare Architektur oder sogar Out-Of-Order.

[Tiamat]

Leider findet man kaum Benchmarks.
Ich hab Specint2000 und Specfp2000 Werte zum Godson 2-E.

Godson 2-E 1Ghz-Version
SpecInt2000 503
SpecFp2000 503

Interessant wäre der Godson 2F mit integrierten Memorycontroller.
Der Godson ist übrigens eine superskalare, out-of-order Architektur.

[HOT]

x86 greift genau deshalb um sich, weil es

1.) immer leichter wird, die zusätzlichen Tranasistoren, die für die x86 Befehlsdekodierung benötigt werden zu beschaffen mit immer besserer und kleinerer Fertigung
2.) immer mehr Befehlssätze keine nativen Chips mehr hervorbringen, sondern auch dort Dekoder zum Einsatz kommen, siehe PPC. Befehlssätze sind nie perfekt, also muss man die eigentliche CPU vom Befehlssatz entkoppeln. Es wird durch diese Entwicklung zunehmend "egaler", welcher Befehlssatz zum Einsatz kommt und für was entscheidet man sich dann im zweifelsfall, wenn eine Lizenz da ist?

Ich finde, Intel müsste dazu gezwungen werden, x86 als freien Standard zu etablieren. Sie müssen ja nicht die Addons freigeben wie Intels SSE oder AMDs x64, aber bis IA32 sollte alles frei sein. Damit würde man die Erfolgsgeschichte merklich beschleunigen.
Ich fände es gut, wenn es einen einheitlichen Befehlsatz für alles gibt. Welcher das ist, spielt keine Rolle, aber dass es nur einer ist, sehr wohl.

[Sorkalm]

Die Patente für das reine x86 dürften inzwischen auch abgelaufen sein...

[Gast]

Ja, jeder moderne PPC dekodiert.
Jeder Prozessor dekodiert. Decode ist die zweite Stufe der klassischen vier- bzw. fünfstufigen RISC-Pipeline.
Dekodieren ist beim PowerPC (im speziellen und RISC im allgemeinen) eine unaufwändige Sache. Bei vielen PowerPCs werden sogar Decode und Dispatch (Verteilen auf die verschiedenen Ausführungseinheiten, Festkommma-, Brach, Load/Store-, Fließkomma und Vektor-Einheit) in einem einzigen Schritt ausgeführt.

Bei einem x86 mit RISC-artigem Kern sind vor dem Dekodieren, wie es auch ein RISC-Prozessor macht, noch zwei weitere Schritte nötig: Decode-x86 und Translate-x86. Beim x86-Dekodieren muss u.a. wegen der unterschiedlichen Befehlslänge relativ aufwendig herausgefunden werden, wo der nächste Befehl beginnt (im Gegensatz zum Dekodieren beim RISC-Prozessor, wo die Befehle alle gleich lang sind). Beim x86-Translate werden dann ein x86-Befehl in mehrere interne Befehle übersetzt. Diese werden dann normal dekodiert und verarbeitet. Die internen Befehle unterscheiden sich deutlich von den x86-Befehlen.

So etwas macht kein PowerPC. Manche (nicht alle) PowerPCs erweitern die PPC-Befehle intern um Metadaten, wie eine ID-Nummer, Gruppenzugehörigkeit o.ä oder teilen bestimmte komplizierte Befehle in zwei einfachere Befehle auf. Es bleiben aber immer noch PowerPC-Befehle.

Dekodieren beim x86 bedeutet etwas ganz anderes, als Dekodieren bei einem RISC-Prozessor. Auch wenn das gleiche Wort dafür verwendet wird.

Der Aufwand für das x86-Dekodieren und x86-Translate ist enorm. Dafür gehen mehrere Millionen Transistoren des kompletten Prozessorkerns von rund 15 Millionen Transistoren ohne Caches drauf. Es werden mehr Transistoren für x86-Decode/Translate gebraucht, als ein ARM-Prozessor für den kompletten Prozessorkern braucht. Dazu ist das noch eine Einheit, die den Stromverbrauch hochtreibt, da sie nicht abgeschaltet werden kann. Wie groß der Aufwand ist, erkennt man schon daran, dass diese Aufgabe in Hardware ausgeführt werden muss.

Das Ganze gilt übrigens nicht für den Atom. Der verwendet die klassische Mikroprogrammierung. Dabei werden die x86-Befehle nicht in RISC-artige interne Befehle übersetzt. Der Atom verwendet den (um SSEx etc. erweiterten) Pentium-P54C-Kern.

[SavageX]

Das Ganze gilt übrigens nicht für den Atom. Der verwendet die klassische Mikroprogrammierung. Dabei werden die x86-Befehle nicht in RISC-artige interne Befehle übersetzt. Der Atom verwendet den (um SSEx etc. erweiterten) Pentium-P54C-Kern.

Auch der Atom überführt x86 in eine eigene neue Darstellung. Lustigerweise lassen sich von einem typischen Programm die allermeisten Befehle 1:1 überführen - aber keineswegs alle.

Und nein, im Atom steckt kein irgendwie erweiterter P54C drin.

Bei den ganzen Vergleichen wie "aus dem Transistorbudget des x86-translate bastel ich einen kompletten ARM" bitte nicht vergessen, wie viele Befehle ein moderners x86-Design pro Takt hinterherschieben kann - die Implementierungen sind halt nicht "die untere Schranke des mit x86 machbaren".

[BlackBirdSR]

Das Ganze gilt übrigens nicht für den Atom. Der verwendet die klassische Mikroprogrammierung. Dabei werden die x86-Befehle nicht in RISC-artige interne Befehle übersetzt. Der Atom verwendet den (um SSEx etc. erweiterten) Pentium-P54C-Kern.

Das hast du irgendwo falsch aufgeschnappt. Sieht man schon an den Blockschaltbildern von Silverthrone und Co.
Ansonsten müsste aber auch der Pentium x86-Befehle in ein internes eigenes, unveröffentlichtes Datenformat umsetzen. Wenn das auch nichts mit RISC oder Decoupled-Execution zu tun hat.

[Gast]

Mit "das Ganze" hatte ich mich ungenau ausgedrückt. Ich bezog mich dabei auf das Translate nach dem Muster, wie es beim P6 (Pentium Pro bis Core) gemacht wird. Also Übersetzen in ein andersartiges (RISC-mäßiges) internes Format mit strikter Trennung zwischen Execute und Load-Store-Befehlen und dann abarbeiten in einer Art RISC-Pipeline.

Beim Atom werden, wie beim Pentium, die Speicheradressen, die in vielen x86-Befehlen enthalten sind, schon im Frontend beim Decodieren aufgelöst und die Daten aus der Adresse geholt. So kann ein Befehl, der eine Speicheradresse enthält, mit den Daten aus dieser Speicheradresse (sozusagen mit einem Pseudo-Immidiate) an das Backend weitergegeben werden. So kommt es, dass sich sich hier die meisten Befehle 1:1 überführen lassen (wie SavageX richtig anmerkt). Im Gegensatz zum Translate nach dem Muster des P6, wo sich kaum ein Befehl 1:1 überführen lässt, weil Speicheradressen im Backend in der Load-Store-Einheit berechnet werden.

Bei der Methode, die beim Atom verwendet wird, spricht man von Mikroprogrammierung, bei der Methode, die beim P6 verwendet wird von Translate.
Der Aufwand für das Umsetzen der x86-Befehle ist in beiden Fällen in etwa gleich groß, beim Translate sogar eher etwas höher. Translate ist aber mehr oder weniger Voraussetzung für Features, wie Out-of-Order etc.

Der P54C-Kern wird im Larrabee verwendet. Der Kern im Atom arbeitet zwar genauso, wie der Pentium-Kern, besitzt aber eine tiefere Pipeline (mit 16 Stufen im Gegensatz zu 5 Stufen).

[BlackBirdSR]

Der P54C-Kern wird im Larrabee verwendet. Der Kern im Atom arbeitet zwar genauso, wie der Pentium-Kern, besitzt aber eine tiefere Pipeline (mit 16 Stufen im Gegensatz zu 5 Stufen).

Ist das nicht etwas zu oberflächlich?
Wir haben doch bereits geklärt, dass in Larrabee eine Weiterentwicklung auf Basis des P54C-Plans arbeitet. Ein P54-C ist es ganz sicher nicht. Siehe AMD64, SSEx, SMT, VT...

Dass Atom genau so wie ein P5 arbeitet, aber eine längere Pipeline besitzt ist auch viel zu krumm. Würde er so arbeiten, bräuchte er keine extra Pipelinestufen. Das Konzept und der abstrakte Aufbau sind sich sehr ähnlich, das stimmt.


Mit "das Ganze" hatte ich mich ungenau ausgedrückt. Ich bezog mich dabei auf das Translate nach dem Muster, wie es beim P6 (Pentium Pro bis Core) gemacht wird. Also Übersetzen in ein andersartiges (RISC-mäßiges) internes Format mit strikter Trennung zwischen Execute und Load-Store-Befehlen und dann abarbeiten in einer Art RISC-Pipeline.

Beim Atom werden, wie beim Pentium, die Speicheradressen, die in vielen x86-Befehlen enthalten sind, schon im Frontend beim Decodieren aufgelöst und die Daten aus der Adresse geholt. So kann ein Befehl, der eine Speicheradresse enthält, mit den Daten aus dieser Speicheradresse (sozusagen mit einem Pseudo-Immidiate) an das Backend weitergegeben werden. So kommt es, dass sich sich hier die meisten Befehle 1:1 überführen lassen (wie SavageX richtig anmerkt). Im Gegensatz zum Translate nach dem Muster des P6, wo sich kaum ein Befehl 1:1 überführen lässt, weil Speicheradressen im Backend in der Load-Store-Einheit berechnet werden.

Bei der Methode, die beim Atom verwendet wird, spricht man von Mikroprogrammierung, bei der Methode, die beim P6 verwendet wird von Translate.
Der Aufwand für das Umsetzen der x86-Befehle ist in beiden Fällen in etwa gleich groß, beim Translate sogar eher etwas höher. Translate ist aber mehr oder weniger Voraussetzung für Features, wie Out-of-Order etc


Jetzt frage ich dich einfach ganz frech, wo sowas stehen soll? Alle Folien, alles was ich bisher gesehen habe spricht eine andere Sprache. Atom nutzt noch immer ein Frontend, welches in diesem Fall in 3 Decode Stufen IA32/AMD64 Instruktionen in interne atomic operations mit festgeschriebener Länge übersetzt - samt Translate natürlich. Sicherlich werden viele Befehle wo immer möglich in nur eine Operation übersetzt. Eine Abarbeitung ähnlich dem P5 gibt es aber meines Wissens nach nicht. 2 relativ einfache Decoder + Mikrorom, alles nicht so weit weg vom PentiumPro-Design.

[Gast]

Ist das nicht etwas zu oberflächlich?
Wir haben doch bereits geklärt, dass in Larrabee eine Weiterentwicklung auf Basis des P54C-Plans arbeitet. Ein P54-C ist es ganz sicher nicht. Siehe AMD64, SSEx, SMT, VT...
Ich würde es eher als P54C-Core mit ein paar Erweiterungen bezeichnen. Der eigentliche Kern muss dafür nicht "weiterentwickelt" werden, nur erweitert.

Dass Atom genau so wie ein P5 arbeitet, aber eine längere Pipeline besitzt ist auch viel zu krumm. Würde er so arbeiten, bräuchte er keine extra Pipelinestufen. Das Konzept und der abstrakte Aufbau sind sich sehr ähnlich, das stimmt.
Man kann die Pipeline-Stufen in kleinere Unterstufen aufteilen, ohne die Funktion der Pipeline an sich zu ändern. So geschehen z.B. beim G4 auf G4e, wo die 4-Stufige Pipeline zu einer 7-stufigen wurde.


Jetzt frage ich dich einfach ganz frech, wo sowas stehen soll? Alle Folien, alles was ich bisher gesehen habe spricht eine andere Sprache. Atom nutzt noch immer ein Frontend, welches in diesem Fall in 3 Decode Stufen IA32/AMD64 Instruktionen in interne atomic operations mit festgeschriebener Länge übersetzt - samt Translate natürlich. Sicherlich werden viele Befehle wo immer möglich in nur eine Operation übersetzt. Eine Abarbeitung ähnlich dem P5 gibt es aber meines Wissens nach nicht. 2 relativ einfache Decoder + Mikrorom, alles nicht so weit weg vom PentiumPro-Design.
Vergleiche einfach mal die Position der Memory-Operationen in der Atom-Pipeline mit der Position in der Core-Pipeline.
In der Atom Pipeline kommen drei "Data Cache Access" Pipeline-Stufen vor der "Execute" Pipeline-Stufe (im Frontend, wie bei einem CISC-Prozessor üblich). Beim Core liegen die Pipeline-Stufen der LSU parallel zu den Execute-Stufen der ALU und FPU im Backend (wie bei einem RISC-Prozessor).
Außerdem schreibt Intel in einer (wohl internen) Folie zum Atom: "Treat basic x86 format with memory operands as one micro op > -load-op-store, load-op execution". Von "atomic" kann hier also nicht die Rede sein.

[BlackBirdSR]

Man kann die Pipeline-Stufen in kleinere Unterstufen aufteilen, ohne die Funktion der Pipeline an sich zu ändern. So geschehen z.B. beim G4 auf G4e, wo die 4-Stufige Pipeline zu einer 7-stufigen wurde.


Ist aber beim Atom nicht der Fall, siehe Pipelinefolien von Intel!


Außerdem schreibt Intel in einer (wohl internen) Folie zum Atom: "Treat basic x86 format with memory operands as one micro op > -load-op-store, load-op execution". Von "atomic" kann hier also nicht die Rede sein.
Doch, atomic im Sinne dass diese Operationen die kleinste Einheit im Backend darstellen. Ein "Micro-Op" für diese Operationen. Das ist nichts anderes, als aus den bisher vielen Micro-Ops wieder eine Einheit zu machen. Ist ja Sinnvoll, wenn man keine größeren OOOe-Fähigkeiten einbaut. Zum P5-Vertreter wird Atom dadurch aber nicht, schau dir bloß den ganzen Rest der CPU an.
Natürlich gibt es gemeinsame Prinzipien, wogegen ich mich jedoch vehement stelle: Atom wäre ein erweiterter P54C oder Atom funktioniert "genauso wie P54C"

[Tiamat]

Gibts da bezüglich personal Roboter irgendwelche Neuigkeiten ?
Das würde mich mal interessieren..

[AnarchX]

Wohlmöglich bald auch Fahrzeugelektronik auf x86-Basis (http://ht4u.net/news/20082_intel-prozessoren_fuer_autoelektronik/)?

[twodoublethree]

Wenn da ne Lebensdauer von 7 Jahren angestrebt ist wird es nicht im Automobilsektor eingesetzt werden können.

Zumindest nicht für integrierte Funktionen die teils auch sicherheitskritisch sind.

[stav0815]

die Elektronik-Halbwertszeit ist aber jetzt teilweise schon deutlich geringer als 7 Jahre. So empfiehlt Audi ab einem Alter von 5 Jahren auch die Airbagsteuergeräte und die ABS/ESP/ASR Steuergeräte zu prüfen.

[twodoublethree]

Zum Prüfen, um sicherzugehen damit alles funktioniert. Aber ein Steuergerät bzw. jedes Elektronikteil ist heute kein Verschleißteil und wird es wohl auch nie werden.

Pyrotechnische Auslöser sollte man glaube ich auch alle 10 Jahre austauschen, funktionieren tut es aber trotzdem in der Regel länger.