Chaos-Theorie soll Mooresches Gesetz ohne neue Transistoren retten

Es wird immer schwerer, durch die weitere Miniaturisierung von Prozessor-Architekturen und die Integration von noch mehr Transistoren weiter die Leistungssteigerungen zu erreichen, die Intel-Mitbegründer Gordon Moore einst als bis heute gültigen ... mehr... Intel, Prozessor, Chip, Wafer, Sandy Bridge Bildquelle: Intel Free Press / Flickr Intel, Prozessor, Chip, Wafer, Sandy Bridge Intel, Prozessor, Chip, Wafer, Sandy Bridge Intel Free Press / Flickr

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Im Prinzip gibt es das ja schon mit den FPGA Prozessoren, nur dass man nicht im Betrieb die Logig-Gatter schnell anpassen kann.
 
@rAcHe kLoS: jup Richt wirklich danach. Intel will ja die FPGA Technik in bestimmte XEONs verbauen. Ich glaub die Branche wird definitiv in diese Richtung gehen. Gerade FPGAs können effektiv Detailprobleme lösen. So Codec Beschleunigungen etc braucht man nicht immer, genau so wie Hardcore AES. Da lässt sich sicher was drehen.
 
Ich sehe einen Sprung nach oben bei der Abwärmefrage voraus. :)

Und einen bei der Leistungsfähigkeit runter. Egal wie man sich das dreht, irgendwie muß das ja implementiert werden, und selbst wenn man das jetzt verzahnt und sagt, okay 50% meiner CPU "leisten" und die anderen fünfzig erstellen die neue Konfiguration und beim nächsten Takt schalten wir das um... dann funktioniert das nur unter der Annahme, daß 'bisher' eh >50% aller Schaltungen zu jeder Zeit irgendwie inaktiv sind.

Ich persönlich stelle das allerdings schon auf dem elektrischen Level in Frage - Stichwort Übersprechen und andere Störeinflüsse. Das ist jetzt vielleicht nur Einbildung auf meiner Seite, aber irgendwie werde ich den Verdacht nicht los, daß sich die Chiphersteller schon seit Jahren mit der Frage "können wir das irgendwie nutzen?" befaßt haben; so heiß sind die sicher nicht darauf, Milliarden und Abermilliarden an Transistoren zu verbauen, *wenn sie es überhaupt nicht müßten*.

Da reden wir noch nicht von der Sicherheitsproblematik. On-the-fly reprogrammierbare Hardware in allgemeiner Verbreitung? Schön für Malware. Nicht so schön für den Endanwender.
 
@RalphS: In der Praxis dürften weit mehr als 50% brach liegen zu einen gegebenen Zeitpunkt bei heutigen Prozessoren. Will man ja auch, siehe Stromsparmechanismen wo nicht nur der Takt gesenkt wird, sondern auch ganze Bereiche des Prozessors inaktiv geschaltet werde. Das ist heute Gang und Gebe.

Bei konstant angenommener Leistung sollte die Abwärme nicht wirklich beeinflusst werden durch das vorgeschlagene Prinzip, da ja nicht mehr Transistoren beteiligt sind sondern nur andere die vorher brach lagen und man daher mit einer geringeren Gesamtzahl an Transistoren auskommt - wie gesagt, bei konstanter Leistung im Vergleich zu heute.

Kann man durch das vorgeschlagene Prinzip mehr der physikalisch vorhandenen Transistoren gleichzeitig nutzen, steigt natürlich die Abwärme, aber damit dann natürlich auch die erreichbare Leistung. Stromsparmechanismen würden bei geringer Auslastung natürlich immer noch greifen und daher würde in der Praxis selbst dann bei vielen Anwendungen kaum merklich mehr Leistung benötigt, nur die Maximalleistung ließe sich dadurch deutlich erhöhen.

Und es gibt keine Sicherheitsproblematik dabei. Nach außen muss das ganze ja genauso funktionieren wie bisher, das geschieht ja rein intern im Prozessor. Ein Programm wird immer noch Add, Sub, etc. Instructions benutzen und ob der Prozessor da jetzt eine feste Anzahl an Transistoren nutzt oder sich so viele gönnt von den physikalisch vorhandenen wie möglich, ist nach außen hin ja völlig egal und wird in keinster Weise den Ablauf beeinflussen. Sicherlich wird es Softwaremöglichkeiten geben das Prozessorverhalten zu steuern, aber das ist heute schon Gang und Gebe. Man kann Kerne deaktivieren, Stromsparmechanismen konfigurieren etc. und all das sorgt ja intern dafür das Teile des Prozessors und damit nen Haufen Transistoren genutzt oder nicht genutzt werden. Auch sind heute die Instruktionen bei x86 z.B. nicht fest verdrahtet sondern bestehen nochmal aus Microcode welcher im Prozessor gespeichert ist und angepasst werden kann. Das passiert häufiger mal durch z.B. das Bios um Fehler im Microcode zu beheben wie es diese z.B. recht prominent beim Core 2 gab.
 
@RalphS: "irgendwie werde ich den Verdacht nicht los, daß sich die Chiphersteller schon seit Jahren mit der Frage "können wir das irgendwie nutzen?" befaßt haben". Richtig ungefähr alle Entwicklung (abgesehen von SIMD) gehen in die Richtung: Out of Order - Execution, Pipelining, Branch Prediction, Caches usw sind alles Mechanismen, die dafür sorgen, dass möglich viele Transistoren etwas tun.
 
@Zreak: Nicht ganz ... das was du beschreibst ist die x86 umstellung von CISC auf RISC Design mit minimalistischen Befehlssatz. Dabei ging es im ersten Ansatz, Kern CPU massiv Takten zu können. Das hat nix mit Transistor und effektivität zutun, da die von dir beschriebene Technik alles andere als Effektiv ist. Es wird einfach große Aufgaben in kleine Zerlegt und einfach in irgend eine Richtung weiter gerechnet. Wenn das Ergebnis passt ... dann wars schneller. Das ist Anno Pentium Pro und von dir beschreiben P4 - Netburst.
 
@WosWasI: Pipelining erlaubt höhere Taktzahlen, indem es die durchschnittliche Idlezeit (Zeit die über die Schaltzeit des einzelnen Transistors hinausgeht) jedes Transistors reduziert und damit höhere Takte erlaubt. Dies führt dazu, dass die Transistoren öfter schalten und hat somit die Auslastung der Transistoren gesteigert. OoO führt dazu, dass die einzelnen Execution Units parallel ausgelastet werden (ein Addieren blockt kein Multiplizieren) und hat somit die Auslastung der Transistoren gesteigert. Caches führen zu weniger Pipeline Stalls und haben somit die Auslastung der Transistoren gesteigert. Branch Prediction führt zu weniger Pipeline Trashing und hat somit die Auslastung der Transistoren gesteigert.
Kommentar abgeben Netiquette beachten!

Video-Empfehlungen