Es gibt eine neue CPU Architektur, die angeblich die Performance eines x86 Boliden mit der Leistungsaufnahme eines DSP kombiniert. Hier der Einstieg: http://ootbcomp.com/docs/belt/ Es gibt noch mehr Videos auf der Seite, die verschiedene Aspekte der neuen Architektur beleuchten. Teilweise ist es sehr interessant. Ich weiß nicht ob dieses hier das richtige Unterforum ist, also ggf. bitte verschieben.
Das große Problem dabei - Programmierer, die sich einmal an ein Modell gewöhnt haben, wollen sich nicht mehr um gewöhnen. Seit Algol haben wir nur mehr Veränderungen in den Details, nicht aber im Modell. Die Probleme, die Godard lösen will, sind ja gerade dadurch entstanden, dass die Prozessoren solche grundlegend neue Konzepte verstecken müssen. Dass sich das Modell des Programmierers nicht wesentlich verändern darf.
Was ich verstanden habe: Die Belt-Architektur kann unter der Oberfläche des Compilers liegen. Da müssten sich die Programmierer nicht umgewöhnen.
Hallo, da Mr. Godard vermutlich nicht die nötige Milliarde Dollar hat, um in die Fertigung einzusteigen, hat das sowieso keine Marktrelevanz. Gruss Reinhard
Gibts das auch als Doku/Präsentation, oder muss man sich da durch 1,5 Stunden Video quälen?
Für mich sieht das so aus, als wenn man wesentliche Elemente eines Out-Of-Order Prozessors in den Compiler verlegen würde. Das hat natürlich den Vorteil, das man viel Logik und insbesondere auch viele komplizierte Speicherelemente wie CAM und Multiport-Registerfiles spart. Problematisch ist bei solchen Ansätzen natürlich immer dass die Binaries nur für eine spezielle CPU optimiert sind. Außerdem gibt es weniger Freiheiten für die CPU Redundanzen und Leerlaufzeiten auszunutzen, die z.B. durch Speicherlatenzen oder im Multithreadind entstehen. Es gab schon häufiger solche Ansätze (siehe z.B. VLIW), die immer wieder an mangelnder Flexibilität gescheitert sind. Durch Moore Law war es nie eine Designkriterium dass man Transistoren sparen musste. Heutzutage wird die Chipfläche von High-End Prozessoren eh durch den Cache dominiert. Es kann aber sein, dass solche Ansätze zur Reduktion der Energiedichte auf Prozessoren wieder interessanter werden. So weit überblicke ich das nicht. Aber es scheint ja noch genug anderen Knöpfe zu geben, die es nicht notwendig machen an der ISA herumzudrehen.
Erinnert mich entfernt an Intels i860 im pipelined mode. Dort hat ein Befehl a := b <op> c zwar die Verarbeitung von b und c gestartet, aber das Ergebnis einer einige Takte davor gestarteten Operation nach a geschrieben, so wie es die Pipeline auswarf. https://en.wikipedia.org/wiki/Intel_i860
Also wenn Tim recht hat, dann ist es doch das gleiche Prinzip wie beim Intel Itanium. Und der ist grandios gescheitert. Solche Ideen klingen ja erstmal gut, aber die Realität sieht anders aus.
... schrieb: > Also wenn Tim recht hat, dann ist es doch das gleiche Prinzip wie beim > Intel Itanium. Und der ist grandios gescheitert. Allerdings nicht so sehr aus technischen Gründen als aus strategischen. Intel wollte sich damit das absolute zupatentierte Monopol sichern, indem die 32-Bit Linie allmählich ausläuft und die Leute über kurz oder lang auf IA64 migrieren müssen. AMD sah die Chance und drehte Intel mit 64-Bit x86 eine Nase. Den Kunden wars recht, Kompatibilität und Preise waren denen wichtiger. Und Intel war gezwungen, AMDs Schritt zu folgen. Ohne AMD wäre IA64 heute der 64-Bit Standard für Server und bessere PCs.
Das Beispiel Itanium zeigt weniger, dass Ansätze in die Richtung kompletter Schwachsinn sind, sondern eher dass eine ISA nicht Marktentscheidend ist. Intel hat z.B. mit dem i960 schon sehr gute Architekturen gehabt, die sich aus den gleichen Gründen auch nicht durchsetzen konnten. Warum so etwas gemacht wird, ist auch offensichtlich: http://de.wikipedia.org/wiki/Embrace,_Extend_and_Extinguish Nur der Markt spielt zum Glück nicht immer mit.
Schwachsinn sind die Ansätze beim Itanium nicht. Rein theoretisch klingt das auch gut. Aber praktisch ist es nicht gut. Es läuft doch darauf hinaus, dass man jede Applikation, die den Prozessor voll ausnutzen soll, für den Prozessor compilieren muss. Da müssten die Softwarehersteller nicht nur für jede Betriebssystemvariante neu compilieren sondern auch noch für jeden Prozessor. Außerdem müssten die Compiler sofort wenn ein Prozessor verfügbar ist auch upgedatet werden. Und das ist unpraktisch und das Problem für jeden Ansatz, der etwas von der Hardware in den Compiler verlagert. Das Problem wäre nicht so kritisch, wenn alle Programme in Bytecode vorliegen und mit einem Just-In-Time Compiler übersetzt werden. Realistisch ist das aber auch nicht.
... schrieb: > Es läuft doch darauf > hinaus, dass man jede Applikation, die den Prozessor voll ausnutzen > soll, für den Prozessor compilieren muss. Jo, aber so exotisch ist das heute nicht mehr. DotNet arbeitet so, Android ebenfalls. > Da müssten die > Softwarehersteller nicht nur für jede Betriebssystemvariante neu > compilieren sondern auch noch für jeden Prozessor. Nope. Sie liefern ein Halbfertigprodukt aus, d.h. Zwischencode. Der wird auf dem Zielsystem mit Installation oder später in optimierten Code übersetzt. Ist nix für top performance, weil der letzte Schliff aus diversen Gründen fehlt, aber für Normalanwendungen gehts. Und für top performance gehts ohnehin nicht anders als mit für den Core spezifischen Code. Ist ja auch nie das ganze Programm, sondern nur kleine Teile davon. Nicht zuletzt weils bei x86 mittlerweile viele verschiedene SSE Versionen gibt. Auch manche Linux Komponenten probieren beim Start erst einmal diverse Code-Varianten für irgendwelchen Kram durch (Blockmove, RAID und so Zeug).
Ja, es gab auch mal Transmeta. Die haben Code in Zwischencode übersetzt, der schneller/flexibler/portabel/effizient sein sollte. Und dann gab es mal Transputer, die sollte im Verbund mit mehreren auch parallel rechnen. Oder die neue XMos-Architektur, Multicore Microcontroller. Das Problem ist, die Leute wollen ihr Windows, Office und jetzt ihr Angry Birds. Alles was nicht kompatibel ist, wird wieder untergehen.
PittyJ schrieb: > Das Problem ist, die Leute wollen ihr Windows, Office Da lag bisher das Problem, > und jetzt ihr Angry Birds. da ist es aber keins. Android Apps sind überwiegend plattformunabhängig, da gibts nicht nur ARM sondern auch Intel.
PittyJ schrieb: > XMos-Architektur, Multicore Microcontroller Die sich ganz ordentlich verkaufen wie man hört. Findet man inzwischen in so einigem digitalen Audio-Interface-Equipment.
> die Leute wollen ihr Windows
... und nehmen dafür Laptops mit Ventilator und 4 Stunden Laufzeit in
Kauf.
Das ändert sich zur Zeit. Mal schauen, ob sich genug Leute finden, die
mehr Wert auf kleinere Geräte mit langer Laufzeit legen.
Der Herr Goddard sagte dazu, dass sie sich zunächst eh erst eine Nische suchen möchten, um von da aus größer zu werden
Kein Name schrieb: >> die Leute wollen ihr Windows > > ... und nehmen dafür Laptops mit Ventilator und 4 Stunden Laufzeit in > Kauf. > > Das ändert sich zur Zeit. Mal schauen, ob sich genug Leute finden, die > mehr Wert auf kleinere Geräte mit langer Laufzeit legen. Na na na... Also aktuelle Laptops mit Windows 8 oder auch Windows 7 und einem i3, i5 oder i7 mobile Prozessor laufen ohne Probleme 4...8 Stunden durch; je nach Ausstattung und Akku natürlich. Mein Laptop mit i7 Quadcore mobile Prozessor macht z.B. locker 6 Stunden durch, wenn ich Visual Studio einsetze oder Office-Dokumente bearbeite.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.