Next Hive?

[yeti]

Next Hive?

256-Core RISC-V Megacluster
https://hackaday.com/2024/05/07/256-cor ... gacluster/

Ok. Nicht wirklich. Ich würd eher 'n CP/M-Cluster bauen, weil dann alle Compiler auf dem System selber laufen könnten. Vielleicht kann man auch mal vertüftelieren was das minimale brauchbare NetBSD-System wäre. Bei dessen Hardwarediversität könnt das sogar echt spannend werden, selbst wenn die exotischsten Teilnehmer emuliert würden.

Zurück zum Link von oben: Seine Kommentare über den Bus und dessen Crash-Erkennung könnten uns auch für andere Projekte Ideeën induzieren. Ich hab eh lieber breite langsame Busse statt hochfrequente serielle Solche.

Wer Bock auf sowas hat öffne bitte einen passenden Thread in einem dafür passenden Subforum.

Rieche ich da AVRs, Propeller1 und ESPchen fleißig mit Unixen und anderen OSen kommunizieren? Vielleicht sogar mit drahtlosen Brücken zwischen Bussegmenten?

Also vielleicht sollten wir Hive-2025 vom Bus-System aus anfangen zu entwerfen. Die Teilnehmer auf diesem Bus dürfen dann gern sehr divers sein!

[digger]

Also technisch klingt das ja schon nett, aber er verwendet RISC-V CPUs mit 48MHz und 2KB SRAM, damit würdest du ja beim Einsatz dann vor den gleichen Problemen stehen wie mit dem Propeller 1. Das sind für heutige Wünsche einfach zu wenig Ressourcen. Es muss ja nicht gleich die Leistungsklasse vom Raspberry Pi sein, aber 3-stellige MHz und RAM in MByte-Größe wären schon nice.

[yeti]

Mir geht's doch nur um das Abguggen seines Busses...

[PIC18F2550]

Auch der Takt lässt mittlerweile zu wünschen übrig.
Da bleib ich lieber noch beim P1.
Und für etwas mehr bums beim P2.

Momentan werkele ich mit dem UA880D rum.

[thiloa]

Also technisch klingt das ja schon nett, aber er verwendet RISC-V CPUs mit 48MHz und 2KB SRAM, damit würdest du ja beim Einsatz dann vor den gleichen Problemen stehen wie mit dem Propeller 1. Das sind für heutige Wünsche einfach zu wenig Ressourcen. Es muss ja nicht gleich die Leistungsklasse vom Raspberry Pi sein, aber 3-stellige MHz und RAM in MByte-Größe wären schon nice.

48 MHz mit 32 Bit Registerbreite fände ich für so ein Projekt jetzt gar nicht mal so schlecht. Die wesentliche Beschränkung sind aber die 2 KiB Ram. So etwas kann einerseits anspornen (siehe Demo Szene), aber auch schnell den Spaß verderben .

Die 2 KiB entsprechen ja gerade einmal dem Cog Ram, und wir wissen ja wie eng das ist (ja, die Code Dichte mag im RISV V etwas höher sein, und der Code liegt vmtl auch im Flash, aber ist trotzdem wenig). Man muss sich nur einmal überlegen, einen Editor mit solchen Anforderungen zu programmieren den man auch wirklich mal realistisch benutzen kann und dafür nicht ein Jahr Entwicklungszeit verschlingt.

Die massive Parallelität ist außerdem bereits eine, wenn nicht gar die wesentliche Hürde beim aktuellen Hive. Realistisch betrachtet laufen in den meisten Programmen drei Threads wirklich parallel: Grafik, Sound, Programm. Die restlichen Cogs warten doch eher aufeinander (z.B: Datei lesen, blockiert das Hauptprogramm i.d.R. solange). Der Hauptgrund für die 3 Propeller beim Hive liegt somit m.E. eher in der Ram und ggf. Pin Knappheit als in der Rechenleistung begründet. Würde man auf dem "Mega Cluster" ein Hive OS entwicklen, würden vermutlich 2-3 Kerne echt arbeiten, und der Rest als Ram Erweiterung sein Dasein fristen .

Der verwendete Controller ist übrigens SMD. Ist DIP keine Anforderung mehr?

[yeti]

Der verwendete Controller ist übrigens SMD. Ist DIP keine Anforderung mehr?

Mich würde nur reizen den Bus da abzuguggen und der ist nicht SMD.