Nigelnagelneues Prozessordesign, wieviel schneller?

[Herr Doktor Klöbner]

Hallo,

angenommen die Entwickler bei Intel oder AMD hätten folgende Vorgabe:

Entwickelt einen vollkommen neuen Prozessor, kompatibel zu gar nichts, soviele Transistoren wie die aktuellen X86, gleiche TDP.

Wäre das um ein mehrfaches schneller, oder wäre das gar kein so großer Leistungsschub ?

[Trap]

Sie haben bei AMD doch schon GCN, das ist 10-100x schneller (bei gleicher TDP dann etwas weniger...).

[Ric]

Entwickeln kann man alles - aber ob´s jemand bezahlen kann??

Dann kommt es auch auf den Anwendungszweck an. Was soll die CPU können. Dann kann man den Transistoraufwand entsprechend einplanen.

Siehe RISC, SPAC oder besser noch Itanium - je nach Anwendungsfall können die sehr gut scallieren. Aber siehe mal was bei Itanium raus gekommen ist.

[Tesseract]

hängt davon ab auf was das ganze optimiert sein soll.
wenn das ding das selbe answendungsgebiet und die selben stärken wie aktuelle x86er haben soll wären sicher ein paar % mehr performance drin - aber nicht viel mehr.

wenn man hingegen das ganze paradigma, anwendungsfeld usw. überdenkt könnte sehr wohl deutlich mehr drin sein (ganze größenordnungen). aber das würde wohl auch einen großen teil der bisher geschriebenen software unbrauchbar machen usw.

[ndrs]

Warten wir ein paar Jahre bis die in die CPU integrierten FPGAs kommen, ausgereift sind und von den SW-Herstellern voll genutzt werden. Ich vermute, dass wir da ähnliche Sprünge erleben könnten, wie bei dem, was der TE andeuten will.
Vollkommen auf die Software entwickelte Hardware. Meiner Meinung nach, wird uns da einiges an Potential erwarten. Problem wird sein, wie weit bis dahin die HDL-Compiler sind und ob sich die Programmierer den Aufwand machen, die Hardware anzupassen.

Aber um nochmal konkret auf die Frage einzugehen: Ich tippe auf Faktor 10-100.

[Aquaschaf]

Wäre das um ein mehrfaches schneller, oder wäre das gar kein so großer Leistungsschub ?

Die Frage kann man nicht wirklich beantworten. Eine Prozessorarchitektur lebt vor allem nicht im leeren Raum; die Performance ergibt sich im Kontext der Compiler-Infrastruktur, und der Anwendungen die dafür geschrieben werden.

[Coda]

Warten wir ein paar Jahre bis die in die CPU integrierten FPGAs kommen, ausgereift sind und von den SW-Herstellern voll genutzt werden.
Träum weiter. Der Großteil ist doch schon mit Parallelisierung überfordert, noch schlimmer mit GPGPU.

Und dann willst du denen Verilog zumuten?

[ndrs]

Und dann willst du denen Verilog zumuten?
Ich weiß, dass das das größte Problem an der ganzen Sache ist. Man kann nur hoffen, dass die automatische Codegenerierung dahingehend weiterentwickelt wird oder SystemC irgendwann auch zur Synthese einsetzbar ist.
Andernfalls wäre noch denkbar, dass es eine Anzahl von Bibliotheken gibt, mit der man sich gewisse Standardblöcke verdrahtet um nur einzelne Programmteile in Hardware ausführen zu lassen. Aber dann kommen wieder die Probleme mit Latenzen, Synchronisation usw...
Jedenfalls wollte ich mit meinem ersten Beitrag nur sagen, dass integrierte FPGAs eine Variante wären, die noch im Bereich des denkbaren sind, um die vom TE gemeinten massiven Verbesserungen zu verwirklichen. Dass x86 oder ARM in den nächsten 20 Jahren komplett über den Haufen wirft halte ich nämlich für kaum machbar. Es sei denn, Intel erhöht die CPU-Geschwindigkeit grad deshalb so langsam, weil sie hinter verschlossenen Türen bereits eine Nachfolgearchitektur haben, die sie aber erst auf den Markt werfen, wenn x86 so schnell emuliert werden kann, wie es aktuell nativ läuft :D

[Tiamat]

Ich kann mir nicht vorstellen, dass eine brandneue Mikroarchitektur in Generation 1 gleich so performant und ausbalanciert wäre wie etablierte x86 Architekturen, bei denen ja schon seit Jahrzehnten Verbesserungen stattfinden und entsprechend gute Compiler vorhanden sind.

[Knuddelbearli]

kommt drauf an wie viel man ausgeben will und wie lange man ihnen zeit gibt ^^

gib ihnen die Finanzielen Mittel von Apple und 5 Jahre Zeit und absolut Freie hand was das Umfeld angeht und die CPUs dürften zig Größenordnungen schneller sein als x86 in 5 Jahren

[Shink]

Warum glaubt ihr, dass es da Potential gibt nach dem Versagen von Itanium, Cell und Transmeta?

AFAIK wurden die ja von Grund auf neu designt - von Leuten die davon durchaus etwas verstehen sollten.
Klar, wenn der nur Proteine falten, Addieren oder was weiß ich was tun können soll ist da schon was drin. Dafür integriert man ja heute GPGPUs in die CPU - und ob die CPU dann X86-Code versteht ist dann auch schon egal.
Einen echten X86-Prozessor gibt es ohnehin schon lange nicht mehr. (Wobei: Bei den VIAs und den Geodes bin ich mir da nicht ganz sicher.)

€: Ist aber jedenfalls ein schönes Thema für Flamewars der Tegra-, Cell-, Apple etc. Fanboys.

[Skysnake]

Träum weiter. Der Großteil ist doch schon mit Parallelisierung überfordert, noch schlimmer mit GPGPU.

Und dann willst du denen Verilog zumuten?
So siehts leider aus :ugly:

Ich erwarte da auch eher geringe Potenziale, wenn man die Architektur an sich ändert. Klar, man kann einiges besser machen, mehr Regist ohne Renameing etc. Aber am Ende wird da wohl nicht viel bei rum kommen, wenn man Software in der Form weiter nutzen will, wie Sie heute gegeben ist.

Ein wirklich großer Schritt wäre für mich z.B. wenn die ganzen OS traps etc. wegfallen würden. Da könnte man je nach Anwendung doch einiges bei raus holen. Ist das aber realistisch unsetzbar? Nein definitiv nicht.

"Integrieren" ist das Zauberwort. Nicht "nue Designen".

Wir haben wirklich gute Sachen. x86 CPUs, GPUs, FPGAs usw. Wenn man wirklich die Effizienz erhöhen will, dann sollte man erst mal so Sachen wie DDR3 weg bekommen. Das Zeug ist einfach ein Stromfresser und langsam.

Ich stell mir da eher ein eDRAM/ReRAM/PCRAM/etc. vor mit doppelter/vierfacher Bandbreite und eben TSV oder Interposer Anbindung an die CPU. Das spart schon mal viel Energie.

Dann als nächstes kommt direkt die dezidierte GPU. WEG DAMIT! Die Anbindung ist viel zu flachbrüstig, dann dazu noch der getrennte Speicher/Adressraum und dann auch noch der hohe Energiehunger des Speichers.... Also auch direkt zur CPU, wie bei den APUs, nur eben viel viel viel fetter.

So als nächster Schritt. 80% der Platine mit ihren ganzen Zusatzchips weg. Alles rein in den CPU,GPU/APU,RAM Verbund. Also nur noch Anschlüsse nach außen führen. UND SCHEIS auf Aufrüstbarkeit. Das erhöht nur die Kosten und braucht mehr Energie als nötig. Muss man sich halt vorher Gedanken machen, was man und die Leute brauchen.

Wir haben eh die dark-chips. Also wayne wenn da noch bischen mehr Ballast mit rum geschleppt wird, der nicht an ist.

So dann haben wir am Ende ein System, wo alles in stacked-Chips integriert ist mit einem PCB von vielleicht 10x10 bis 15x15 cm.

PS: Ja, wir werden dann auch die ganzen unterschiedlichen Spannungen los... Genau eine Spannung kommt vom Netzteil, und das wars. Mehr is nicht.

Ach so und wir führen bitte instant die 400mm+ Wafer ein, damit die Sachen auch halbwegs bezahlbar bleiben.

Wir müssen das gesamte Ecosystem ändern, in dem eine Architektur arbeitet. Die Architektur an sich ist doch eh schon mit allem möglichen Vollgestopft, um Sie zu verbessern. Da wird ein Umstieg von x86 auf YZ auch nicht sonderlich viel bringen.

[Nighthawk13]

Aber dann kommen wieder die Probleme mit Latenzen, Synchronisation usw...

So siehts aus, ich hör den FPGA-Entwickler-Kollegen ständig fluchen über Timing-Probleme. Was Anwendungslogik geht, haben wir die grösstenteils vom FPGA rausgezogen und lassen nur noch die hardwarenahe Ansteuerung darauf.

Seitdem bin ich dankbar für den Luxus, einen getesteten ASIC programmieren zu dürfen, und sei es in ASM oder Cuda;)

[Tiamat]

Warum glaubt ihr, dass es da Potential gibt nach dem Versagen von Itanium, Cell und Transmeta?

AFAIK wurden die ja von Grund auf neu designt - von Leuten die davon durchaus etwas verstehen sollten.
Klar, wenn der nur Proteine falten, Addieren oder was weiß ich was tun können soll ist da schon was drin. Dafür integriert man ja heute GPGPUs in die CPU - und ob die CPU dann X86-Code versteht ist dann auch schon egal.
Einen echten X86-Prozessor gibt es ohnehin schon lange nicht mehr. (Wobei: Bei den VIAs und den Geodes bin ich mir da nicht ganz sicher.)

€: Ist aber jedenfalls ein schönes Thema für Flamewars der Tegra-, Cell-, Apple etc. Fanboys.

Wobei VLIW wirklich ein interessantes Konzept ist. Ich glaube der Crusoe hatte deswegen keine guten Karten, weil der Softwaremarkt bei x86 überhaupt nicht darauf ausgelegt ist. Das X86 Codemorphing ist vielleicht auch nicht so effizient ausgefallen wie das beabsichtigt war.
Dazu bedarf es schon einer extra darauf ausgerichteten Plattform.

Ich kann es nachvollziehen warum sich z.B Intel mit EPIC austobt.
Vom Konzept her ist VLIW/EPIC x86 weitaus überlegen. Doch auch hier sieht man, dass es etliche Generationen benötigt, bis man gewisse Effizienzgrade erreicht.

[ndrs]

So siehts aus, ich hör den FPGA-Entwickler-Kollegen ständig fluchen über Timing-Probleme. Was Anwendungslogik geht, haben wir die grösstenteils vom FPGA rausgezogen und lassen nur noch die hardwarenahe Ansteuerung darauf.
Wenn ich dich jetzt richtig verstanden habe, den umgekehrten Weg gehen wir gerade für eine Nanopositioniermaschine. Falls dir PXI was sagt (Core2Duo für die Algorithmen, FPGAs für I/O), da wird grad ein Teil der Rechenlogik in die FPGAs verschoben, weil die Latenzen einfach zu hoch sind um die 100kHz Regelfrequenz einzuhalten. Dann kommen die aber an ihre Leistungsgrenzen .... alles nicht so einfach.
Aber ich schweife vom Thema ab.

[Skysnake]

kommt halt immer aufs Problem drauf an ;)

[Nighthawk13]

Wenn ich dich jetzt richtig verstanden habe, den umgekehrten Weg gehen wir gerade für eine Nanopositioniermaschine. Falls dir PXI was sagt (Core2Duo für die Algorithmen, FPGAs für I/O), da wird grad ein Teil der Rechenlogik in die FPGAs verschoben, weil die Latenzen einfach zu hoch sind um die 100kHz Regelfrequenz einzuhalten. Dann kommen die aber an ihre Leistungsgrenzen .... alles nicht so einfach.
Aber ich schweife vom Thema ab.
Ja das ist genau die Nische wo FPGAs ihre Daseinsberechtigung haben und auch kaum ersetzt werden können: Hardwarenahe Anbindungen mit harten Timinganforderungen(Bei 100KHz gehört da die Regelschleife noch dazu.)

Ausserhalb dessen ist der Entwicklungsaufwand einfach zu hoch(man kann zu leicht Fehler machen die nur sporadisch auftreten und schwer zu durchschauen sind. Dazu die lange Build-Zeit).

So ein Zwischending ist es noch, ein "Soft-CPU"-Design in den FPGA mit einzubauen. Dann kann man zumindest die Kontrollogik in Software programmieren.

[Shink]

Ich glaube der Crusoe hatte deswegen keine guten Karten, weil der Softwaremarkt bei x86 überhaupt nicht darauf ausgelegt ist.
Ich denke die Probleme waren vielseitig. Die Codemorphing-Software lag im RAM, der Cache war irgendwie ziemlich klein für einen VLIW... naja, Hauptaugenmerk war schließlich Stromverbrauch und nicht Performance.
Fand ich jedenfalls schade, dass man die Architektur ganz eingestellt hat.

[Coda]

Man kann nur hoffen, dass die automatische Codegenerierung dahingehend weiterentwickelt wird oder SystemC irgendwann auch zur Synthese einsetzbar ist.
SystemC löst das Problem nicht.

Es wird manches leichter synthetisierbar, aber das Paradigma von Hardware-Beschreibung ist immer noch das selbe.

Man kann damit auch nicht beliebigen C++-Code in Hardware umwandeln, falls du das glaubst.

Vom Konzept her ist VLIW/EPIC x86 weitaus überlegen. Doch auch hier sieht man, dass es etliche Generationen benötigt, bis man gewisse Effizienzgrade erreicht.
Das halte ich für einen Mythos. Das Problem bei VLIW und einem Prozessor ist, dass die Instruction-Groups völlig rigide sind, was Probleme beim Out-Of-Order-Scheduling erzeugt. Das ist aber wichtig um Speicher-Latenzen zu verstecken. Der nächste Itanium geht deshalb auch ironischerweise weg vom festen EPIC-Scheduling.

VLIW ist dort sinnvoll, wo man diese Probleme nicht hat, also massiv parallele Systeme wie GPUs.

[ndrs]

Man kann damit auch nicht beliebigen C++-Code in Hardware umwandeln, falls du das glaubst.
Ich weiß, dass es nur eine Bibliothek ist, aber die Einstiegshürde liegt sicherlich deutlich niedriger. Es sollte auch nur als grobes Beispiel gemeint sein. Selber hab ich mich auch nur mit VHDL beschäftigt.

[Coda]

SystemC sieht nur aus wie C++, du musst trotzdem Signallaufzeiten berücksichtigen, die Clock verteilen etc. pp. Es ist auch nur eine sehr begrenztes Untermenge überhaupt synthetisierbar.

Ich sehe nicht warum die Einstiegshürde damit "deutlich" niedriger sein sollte.

[Tiamat]

Das halte ich für einen Mythos. Das Problem bei VLIW und einem Prozessor ist, dass die Instruction-Groups völlig rigide sind, was Probleme beim Out-Of-Order-Scheduling erzeugt. Das ist aber wichtig um Speicher-Latenzen zu verstecken. Der nächste Itanium geht deshalb auch ironischerweise weg vom festen EPIC-Scheduling.

VLIW ist dort sinnvoll, wo man diese Probleme nicht hat, also massiv parallele Systeme wie GPUs.

Finde ich zumindest schon. Man stelle sich vor Frontend und Backend sind homogen(es müssten nicht mehr x86 Operationen in µops umgewandelt werden), dynamische Befehlslänge entfiele und man könnte sich die Transistoren für das komplette dynamische Out-of-Order Scheduling sparen. Man vergleiche einen DIE Shot einer x86 CPU mit einem DIE Shot eines VLIW/EPIC Prozessors. Der Unterschied ist beachtlich, wie schlank das erscheint. Da is jede Menge Platz auf dem DIE. Das zeigt sich dann auch im Stromverbrauch, zugegeben beim Itanium nicht.

Man betrachte diesen Codeteil


for(i = 0; i < n; i++) {
...
}


Wie viel mal wird das ganze auf einer herkömmlichen CPU ausgeführt. Soviel Schleifenschritte wie der Betrag von n ausfällt, skalare Befehlsausführung halt.
Auf VLIW Maschinen wird nur ein Bruchteil von n ausgeführt und es müssen auch nur ein Bruchteil der Befehle aus dem Speicher geladen und dekodiert werden. Schleifen entfallen sogar häufig im zugehörigen Assemblercode. Das hat meiner Meinung sogar das Potential mal richtig durch eine geeignete Programmiersprache supported zu werde. Das würde vielleicht sogar die Art und Weise von Programmierung ändern.
Threadprogrammierung könnte damit revolutioniert werden.
Ich sehe da nur eigentlich nur Vorteile.

Das der Compiler nicht immer den optimalsten Code erzeugt, meines Erachtens bei x * 3Ghz nachnachlässigbar. Was bleibt ist ist eine immense
Transistor und Stromeinsparung, die auch deswegen zurückzuführen ist, weil die CPU für gleiche Funktionalität weniger Befehle ausführen muss und wie gesagt somit weniger langsame Speicherzugriffe stattfinden. Falls eben irgendwelche Pipelines leer sein sollten, wird eben kräftig Strom gespart.

[Gipsel]

Schlechtes Beispiel.
Je nachdem was in der Schleife genau passiert, vektorisiert das der Compiler und gegenüber SIMD hat VLIW im Effizienzbereich sogar Nachteile. Selbst ohne Vektorisierung macht der Compiler auch auf skaleren Architekturen ziemlich sicher Loop-Unrolling, womit Dein ganzes Argument hinfällig wird. Und effiziente Codierung durch komplexe ISAs ist auch ein Vorteil (kompakter Code, besseres Caching) und kann nicht wirklich ein großes Problem sein (okay, x86 ist ein wenig häßlich), da z.B. auch ARM und GPUs ISAs mit variablen Instruktionslängen nutzen.

[Tiamat]

Ob er es unrollt oder nicht, es wird n mal ausgeführt und ist damit schon ein kräftiger Nachteil.
Das Problem ist wie viele Entwickler programmieren denn SIMD, ich kenne keine einzigen und die Unterstützung von Compilern dürfte mau sein.

[Gipsel]

Ob er es unrollt oder nicht, es wird n mal ausgeführt und ist damit schon ein kräftiger Nachteil.Du weißt schon, daß ein superskalarer Prozessor (mit ein wenig Mithilfe vom Compiler) in dem Fall die Scheifeniterationen überlappen, mithin parallel abarbeiten kann? Auch der Schleifenkörper wird dadurch nur n/unrolling-count mal ausgeführt. Hast Du ein 4 Operationen breites VLIW, kommst Du schon mit 4fachen Unrolling auf den gleichen Effekt (und bei einer vergleichbar breiten superskalaren Architektur auf mindestens die gleiche Performance).
Das Problem ist wie viele Entwickler programmieren denn SIMD, ich kenne keine einzigen und die Unterstützung von Compilern dürfte mau sein.Soo mau ist die gar nicht. Solche for-Schleifen wie von Dir sind geradezu prädestiniert für Vektorisierung und Loop-Unrolling.

[Tiamat]

Das tut dem Nachteil keinen Abbruch. Sagen wir n = 1024 dann rechnet eben jede Recheneinheit 256 Befehle wenn es 4 Recheneinheiten gibt im optimalen Parallelfall aber es muss auf jeden Fall getan werden.
Bei VLIW kommt eine primitive Schleife vielleicht mit 6 Befehlen aus, das ist ein Mordsunterschied.

Was SIMD und Compiler angeht, hab ich hier ein Beispiel. G++ 4.x Xcode 3.

Die primitivste For-schleife, die man sich vorstellen kann, rechts der Assemblercode.
http://img577.imageshack.us/img577/5530/picx.gif

Noch mal GCC. Wenn man nicht die builtin SEE Funktionen von GCC nutzt, oder mit <xmm.h> do it yourself SEE programmiert, fällt die Unterstützung sehr sehr sehr flach aus.

[Gipsel]

Ich glaube, mit einem cout in der Schleife müssen wir nicht mehr diskutieren.

[Tiamat]

int x[1024], y[1024], a = 5;
// .... irgendwelche Befüllungen
for(int i = 0; i < 1024; i++) {
y[i] = a * x[i] + y[i];
}



Pro Schleifenschritt 14 Befehle * 1024 Schritte = 14336 Befehle. Der Compiler unrollt hier nix und SIMD kommt auch nicht zum Einsatz.

Bei VLIW benötigt die ganze Schleife 6 Befehle.

[Gipsel]

Dann hast Du erstens einen schlechten Compiler (oder Optimierungen aus) und zweitens ist Deine Befehlsanzahl vollkommen off.

Edit:
Gerade mal nachgesehen, schon MSVS2005 (das kann noch keine Vektorisierung) betreibt ein 32faches Loop-Unrolling bei der Schleife im Release-Modus (alles Standard, nix aggressives per Hand geändert).

[Trap]

Braucht man in dem Fall bei modernen CPUs überhaupt unrolling?

GCC 4.6.2 erzeugt für den Beispielcode oben übrigens Vector-Befehle (mit -O3 -march=corei7 )

[Tiamat]

Sorry ich hatte Debug Mode an xD
Ja ich seh´s grad : im Release-Mode erkenn ich xmm Register die benutzt werden, also SIMD.
Das ganze scheint sich wild zu verzweigen, ich kann leider momentan keine Aussage darüber treffen, wie viele Instruktionen ausgeführt werden. Das wäre hier interessant.

[Trap]

Mit -O3 -march=core-avx-i kommt als Schleife raus:
L4:
vmovdqu (%ecx,%eax), %xmm0
vmovdqu (%edx,%eax), %xmm1
vpmulld %xmm2, %xmm0, %xmm0
vpaddd %xmm1, %xmm0, %xmm0
vmovdqu %xmm0, (%edx,%eax)
addl $16, %eax
cmpl $4096, %eax
jne L4
Sind 2048 Befehle. Wieviel Takte das braucht müsste man praktisch ausprobieren...

[Tiamat]

Wow ok, das ist kompakt.
Jetzt der ASM Code von einem reinen Vektorrechner.


L.D F0, a
LV V1, Rx
MULVS.D V2, V1, F0
LV V3, Ry
ADDV.D V4, V2, V3
SV Ry, V4

[Gipsel]

Braucht man in dem Fall bei modernen CPUs überhaupt unrolling?Es hilft, Latenzen zu verstecken, weil mehr unabhängige Instuktionen zur Verfügung stehen.

GCC 4.6.2 erzeugt für den Beispielcode oben übrigens Vector-Befehle (mit -O3 -march=corei7 )Sag' ich doch! ;)
Die Sache mit Integern ist sowieso etwas zweifelhaft, da auch bei VLIW-CPUs normalerweise die Anzahl an Integer-Multipliern arg begrenzt ist. Mit Floats wird es schon lustiger, da reicht normales SSE zum Vektorisieren. ICC11 spuckt dann das für die Schleife aus:
00401032 movaps xmm1,xmmword ptr [esp+eax*4]
00401036 movaps xmm2,xmmword ptr [esp+eax*4+10h]
0040103B mulps xmm1,xmm0
0040103E mulps xmm2,xmm0
00401041 addps xmm1,xmmword ptr y[eax*4]
00401049 addps xmm2,xmmword ptr [esp+eax*4+1010h]
00401051 movaps xmmword ptr y[eax*4],xmm1
00401059 movaps xmmword ptr [esp+eax*4+1010h],xmm2
00401061 add eax,8
00401064 cmp eax,400h
00401069 jb wmain+32h (401032h) Ein nochmalig verdoppeltes Unrolling beschleunigt das übrigens vermutlich kaum noch, da das die OoOE-Engine der CPU schon ganz gut selber hinbekommt.

[Coda]

Es hilft, Latenzen zu verstecken, weil mehr unabhängige Instuktionen zur Verfügung stehen.
Tun sie doch gar nicht, die CPU kann ja auch in mehrere Schleifen-Iterationen reinspekulieren. Die virtuellen Abhängigkeiten dürften mit Register-Renaming auch nicht ins Gewicht fallen.

Ich bin mir da nicht so sicher ob ein i7 wirklich noch davon profitiert. Der hat ja auch Loop-Detection und hält dann selbst die Instructions schon dekodiert vor und solche Späße.

[Gipsel]

@Coda:
Auf diese Fähigkeiten moderner CPUs spielte ich mit dem letzten Satz meines vorigen Postings an. Bei älteren hilft es im Vergleich mehr. Für relativ kurze Loops vermindert es auch den Schleifen-Overhead (die unvektorisierte Version des MSVC 2005 unrolled nicht ganz umsonst ziemlich stark).

Edit: Wenn man dem ICC befiehlt, für eine neuere CPU zu optimieren, hört er mit dem Unrolling übrigens auf, vermutlich, damit die decodierten µOps in den Loop-Stream-Buffer passen (der ist ja nicht übermäßig groß). Da greift also anscheinend genau das, was Du sagst.

[Acid-Beatz]

Ich würd grad ganz lapidar sagen: Wir haben heute nur noch leistungsfähige Architekturen mit leistunsfähigen Compilern ... egal wo man die ansiedelt.


Greez

[ftw]

Hier gibt es einen interessanten CPU-GPU-FPGA-Performancevergleich:
https://en.bitcoin.it/wiki/Mining_hardware_comparison

[ndrs]

SystemC sieht nur aus wie C++, du musst trotzdem Signallaufzeiten berücksichtigen, die Clock verteilen etc. pp. Es ist auch nur eine sehr begrenztes Untermenge überhaupt synthetisierbar.

Ich sehe nicht warum die Einstiegshürde damit "deutlich" niedriger sein sollte.
Ok, ich geb mich geschlagen :) Ursprünglich wollte ich SystemC nur als Beispiel anbringen auf dem man aufbauen könnte, nicht eine Diskussion über die tatsächliche Sinnhaftigkeit lostreten. Der Rest waren nur (offenbar falsche) Spekulationen meinerseits, die auf den dunkelsten Erinerungen einer längst vergangenen HDL-Vorlesung beruhen :)

[Surtalnar]

Interessant wäre auch mal ein niegelnagelneues OS-Design, das würde leistungsmäßig viel mehr bringen, wenn man bedenkt wie viel Altlasten die jetzigen Betriebssysteme in sich tragen.

[Coda]

Welche?

[Shink]

Interessant wäre auch mal ein niegelnagelneues OS-Design, das würde leistungsmäßig viel mehr bringen, wenn man bedenkt wie viel Altlasten die jetzigen Betriebssysteme in sich tragen.
Man kann die ganzen Abstraktionen entfernen und alles im User Space laufen lassen. Das ist nur leider unwartbar, extrem unsicher und erhöht den Aufwand beim Anwendungsentwickler erheblich. Alle bisherigen Versuche, ein Exokernel-Betriebssystem auf die Straße zu bringen, sind AFAIK nach ein paar Prototypen mit erstaunlichen Benchmarkwerten gescheitert.
€: siehe z.B.: http://www.ece.cmu.edu/~ganger/papers/exo-sosp97/exo-sosp97.html

Nicht umsonst setzt man heute selbst bei embedded Hardware auf den fetten Linux-Kernel bzw. lässt sogar eine weitere Abstraktionsebene laufen (VMs).

[Inf1del]

Man könnte auch das Thread Scheduling in Hardware machen.