Hat sich hier schon mal jemand mit den Transputer-Prozessoren aus den 1980ern auseinandergesetzt? https://de.wikipedia.org/wiki/Transputer Würde es Sinn machen, die Prinzipien zur Parallelverarbeitung direkt auf die heutigen MCUs zu übertragen? Da diese ziemlich billig sind, könnte man ja viele miteinander verbinden. Transputer gab es von ST wohl in verschiedenen Wortbreiten: http://transputer.classiccmp.org// T225 16-bit Transputer T425 32-bit Transputer ST20450 32-bit Transputer T400 32-bit Low cost Transputer T805 32-bit Floating Point Transputer T9000 32-bit Floating Point Transputer
:
Verschoben durch Moderator
Das limitierende ist die Kommunikation zwischen den Nodes. Deshalb packt man die Recheneinheiten sehr nah zusammen, und gibt denen gemeinsamen Speicher mit hoher Bandbreite. Z.B. auf einer Grafikkarte, wo x-tausend CUDA-Cores gleichzeitig vor sich hin werkeln.
Beitrag #7955399 wurde von einem Moderator gelöscht.
Ernst schrieb:
>Das limitierende ist die Kommunikation zwischen den Nodes.
Es wird von 10-20MBIt/s gesprochen. Das ist eine Geschwindigkeit, die
man z.B. mit zwei PiPicos auf einer Platine gut erreichen sollte.
Mich interessiert, ob es Sinn machen würde, verschieden Prinzipien auf
z.B. die PiPicos zu übertragen.
Moin, Christoph M. schrieb: > Mich interessiert, ob es Sinn machen würde, verschieden Prinzipien auf > z.B. die PiPicos zu übertragen. Es wird wohl stark davon abhaengen, was du mit deinen PiPicos berechnen willst. Es ist ja nicht verboten, viele von den Dingern miteinander kommunizieren zu lassen. Aber es ist auch nicht immer dringend noetig. Gruss WK
Enge Kopplung über gemeinsamen Speicher ist wesentlich umgänglicher in paralleler Programmierung, als kommunikative Kopplung wie bei Transputern. Der Aufwand der Kommunikation ist beträchtlich. Da man heute hunderte leistungsfähiger und speichergekoppelter Nodes in einem Modul unterbringen kann, Tendenz weiter steigend, fehlt der Sinn der Parallelisierung der Transputer, unterhalb der Ebene von HPC in Saalgrösse.
:
Bearbeitet durch User
Christoph M. schrieb: > Es wird von 10-20MBIt/s gesprochen. Das ist eine Geschwindigkeit, die > man z.B. mit zwei PiPicos auf einer Platine gut erreichen sollte. Immerhin hatten die Transputer wesentliche Elemente der Kommunikation in Hardware gegossen, bis hin zur Signalisierung damit in Verbindung stehender Tasks. Das fehlt hier.
Christoph M. schrieb: > T9000 32-bit Floating Point Transputer Randinfo: Dessen exorbitanter Abstand zwischen Ankündigung und Fertigstellung schloss das Kapitel ab. Schon die hardwaregestützte Kommunikation innerhalb grösserer Gebilde wurde zum Problem, d.h. wenn nicht nur direkte Nachbarn miteinander kommunizieren. Und das Arbeitsprinzip der Architektur, der Stack, war problematisch, weil es sich verfahrensbedingt nur mit damals hohem Aufwand signifikant beschleunigen liess. Bald kamen erste superskalare Architekturen auf, die also mehrere unabhängige Operationen parallel bearbeiteten, was in dieser Phase der Implementierungen aufgrund der Abhängigkeit aufeinanderfolgender Befehle einer Stack-Architektur wenig bringt.
:
Bearbeitet durch User
Angehängte Dateien:
-
TransputerLink.png
160 KB
von (prx) A. K. (prx) >Immerhin hatten die Transputer wesentliche Elemente der Kommunikation in >Hardware gegossen, bis hin zur Signalisierung damit in Verbindung >stehender Tasks. Das fehlt hier. Wenn ich das richtig verstehe, werden beim Transputer Link auf einer Leitung 11Bit gesendet, dann wird die Richtung umgeschaltet und auf das 2Bit Acknowledge gewartet. Das lässt sich wohl mit der PiPico PIO machen: https://github.com/blackjetrock/picoputer
Xmos mit den Links geht in diese Richtung, es gibt/gab auch ein Board mit 64 Einheiten welche untereinander verbunden waren. Als sie sich noch nicht auf Audio fokussierten gab es zwei unterschiedliche Architekturen, eine low cost, LX glaube ich und eine teure, gx. Diese hatten inkompatible HW links und token damit man diese leider nicht kombinieren könnte.
Chris S. schrieb: > Xmos mit den Links geht in diese Richtung Was wenig verwundert, wenn man sich ansieht, welcher Name dahinter steht.
Hier gibt es noch das Video zum PiPico-Transputer Link: https://retrocomputingforum.com/t/raspberry-pi-pico-transputer-emulator/2068
:
Bearbeitet durch User
Christoph M. schrieb: > Würde es Sinn machen, die Prinzipien zur Parallelverarbeitung direkt auf > die heutigen MCUs zu übertragen? Es gibt ja Multicore-MCUs (z.B. ESP32, manche STM32, TriCore) die primär über shared-memory kommunizieren. Das scheint sich so wohl mehr durchgesetzt zu haben als Transputer. Tatsächlich geht es dabei auch weniger um das Erreichen höherer Rechenleistung, sondern Entkopplung von nebenläufigen Vorgängen. Will man mehr Rechenleistung, nimmt man größere Prozessoren (z.B. Cortex-A). Das kann man ziemlich weit treiben (z.B. AWS Graviton). Oder die erwähnten GPUs, APUs.
Da schneidest du ein heisses Thema an. Mit dem Inmos T800 habe ich mich mal auseinandergesetzt, irgendwo liegt noch ein Scan des TRM. Das Problem an der Architektur: Sie war zu frueh dran. Das naechste: Die Entwicklungstools exotisch (Occam wollte einfach vor allem missverstanden werden). Auf jeden Fall keine schlechte Idee, sich mit dem verwaisten Knowhow zu beschaeftigen, denn die Transputerkonzepte findet man - abseits von XMOS - doch oefters in FPGA-Designs wieder, wo Software und Hardware ineinander uebergeht. Nur bei MCUs finde ich es eher fragwuerdig. Sinn macht das Ganze sowieso nur, wenn man alles in die Simulation stecken kann, denn sequentielles Debugging ist da nicht mehr zielfuehrend.
Martin S. schrieb: > Auf jeden Fall keine schlechte Idee, sich mit dem verwaisten Knowhow zu > beschaeftigen, Bei Hobbys ist die Sinnfrage meist nutzlos. Martin S. schrieb: > denn die Transputerkonzepte findet man - abseits von XMOS > - doch oefters in FPGA-Designs wieder, Alles Exoten.... Auch der GA144 von Green Arrays verwendet sowas wie das Transputer Link Konzept.
Martin S. schrieb: > Das Problem an der Architektur: Sie war zu frueh dran. Sie kam immerhin zu einem Zeitpunkt, der zu allerlei Projekten an Universitäten einlud. Da kommen exotische Ideen gut an. Sie war aber engstirnig ausschliesslich auf Programmierung in Occam konzipiert. Was Occam nicht benötigte, das gab es nicht. Was einem bei der Implementierung anderer Programmiersprachen auf die Füsse fiel.
:
Bearbeitet durch User
Martin S. (strubi) 23.10.2025 16:15 >Das Problem an der Architektur: Sie war zu frueh dran. Das naechste: Die >Entwicklungstools exotisch (Occam wollte einfach vor allem >missverstanden werden). Hier gibt es ein interessantes Video zur Entstehung des Transputers: https://www.youtube.com/watch?v=qJVStORkjnM Das interessante: Es wurde zuerst die Programmiersprache "Occam" für parallel arbeitende Prozessoren und danach die dafür optimierte Prozessorarchitektur des Transputers entwickelt. Heraus kam dann eine gemischte Architektur (laut Video, ich habe mir den Befehlssatz noch nicht genau angesehen) aus Stackmaschine und Registermaschine. Dass eine Stackmaschine ziemlich optimiert in ein FPGA passen kann, zeigt Exacamera mit der J1: https://excamera.com/sphinx/article-j1a-swapforth.html
Christoph M. schrieb: > T225 16-bit Transputer > T425 32-bit Transputer > ST20450 32-bit Transputer > T400 32-bit Low cost Transputer > T805 32-bit Floating Point Transputer > T9000 32-bit Floating Point Transputer Da hast du die "Multimedia-Transputer" noch übersehen, die wie der ST20450 zur ST20-Serie gehören, und neben ihrem Transputerkern noch reichlich Peripherie für Audio und Video mitbringen. Wenn man wollte, gab es dafür sogar Betriebssysteme wie OS20, OS21 oder OSPlus. Die Typenbezeichnungen deuten keine Verwandtschaft an: ST51xx, ST77xx, und sicher noch ein paar mehr. Mit 32 bit, Taktraten von ca. 250 MHz, und Single-Cycle-Befehlen dürften die auch jeden Pico leicht an die Wand rechnen. ☺
Angehängte Dateien:
-
ST20450.png
120 KB
>Da hast du die "Multimedia-Transputer" noch übersehen, die wie der >ST20450 Hmm, 40MHz .. https://transputer.net/ibooks/dsheets/st20450.pdf Sind aber wahrscheinlich auch ziemlich historisch.
Christoph M. schrieb: > Würde es Sinn machen, die Prinzipien zur Parallelverarbeitung direkt auf > die heutigen MCUs zu übertragen? In dem Zusammenhang könnte dich der Parallax Propeller interessieren, den man tatsächlich noch kaufen kann. https://www.parallax.com/propeller/
Cartman E. (cartmaneric) 23.10.2025 17:03 >Mit 32 bit, Taktraten von ca. 250 MHz, und Single-Cycle-Befehlen >dürften die auch jeden Pico leicht an die Wand rechnen. Das könnte eng werden. Wenn ich es Recht weiß, lässt sich der RP2350 auf 400MHz übertakten. Er hat zwei Kerne, deutlich mehr Register und immerhin 512kRam im Direktzugriff.
Nemopuk (nemopuk) 23.10.2025 17:26 >In dem Zusammenhang könnte dich der Parallax Propeller interessieren, >den man tatsächlich noch kaufen kann. Ich habe noch 10 Stück rumliegen .. Architektonisch sehr interessant, aber eher in der C64 Ära anzusiedeln. Der Propeller1 hat nur Integer Arithmetik und nur 2K COG-Memory.
Cartman E. schrieb: > Mit 32 bit, Taktraten von ca. 250 MHz, und Single-Cycle-Befehlen > dürften die auch jeden Pico leicht an die Wand rechnen. ☺ Bei den klassischen Transputern wie T4xx waren Taktfrequenzvergleiche mit den aufkommenden RISC Architekturen völlig wertlos. Die Transputer benötigten für die gleiche Aufgabe erheblich mehr Befehle.
Angehängte Dateien:
-
STI55xx.png
31 KB
Christoph M. schrieb: >>Da hast du die "Multimedia-Transputer" noch übersehen, die wie der >>ST20450 > > Hmm, 40MHz .. > https://transputer.net/ibooks/dsheets/st20450.pdf > Sind aber wahrscheinlich auch ziemlich historisch. Die ST-55xx haben auch noch eine PLL zum vervielfachen. Im Beispiel von einem STi-55xx. Es gibt noch schnellere, deren DB mir nicht vorliegt. Ich habe hier zwei Boards die mit 243 MHz (9 * 27 MHz) CPU-Takt laufen.
:
Bearbeitet durch User
Martin S. schrieb: > Da schneidest du ein heisses Thema an. Mit dem Inmos T800 habe ich mich > mal auseinandergesetzt, irgendwo liegt noch ein Scan des TRM. Gehörtest Du etwa zu den wenigen 100 Leuten, die damals eine ATW800 hatten?
Christoph M. schrieb: > Hat sich hier schon mal jemand mit den Transputer-Prozessoren aus den > 1980ern auseinandergesetzt? Ja. > Würde es Sinn machen, die Prinzipien zur Parallelverarbeitung direkt auf > die heutigen MCUs zu übertragen Nein. Alles fürchterlich langsam. CUDA lernen ist klüger.
Michael B. schrieb: > CUDA lernen ist klüger. Habe neulich erst damit begonnen, CUDA auf einem AT90S1200 zu implementieren. Sobald ich damit fertig bin, dann sofort auf 'nem Tiny.
Was mich ein wenig wundert beim Transputerlink: Es gibt jeweils eine Link-Out und einen Link-IN, aber es wird z.B. für jeden Link die Richtung umgeschaltet, um das Acknowledge zurück zu senden. Wäre es nicht sinnvoller gewesen, die Richtung beizubehalten und wie bei einer seriellen Leitung das Acknowledge per RX zurück zu senden?
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.