Autor: Vladas Saulis, PE Prodata, Klaipėda, Litauen

18. Mai 2024

Abstrakt
In diesem Artikel wird ein neues Programmiermodell vorgestellt, das Multi-Core-CPU-Systeme auf einfache und automatisch ausgeglichene Weise nutzen kann. Dieses Modell schlägt auch ein einfacheres Programmierparadigma für die Entwicklung paralleler Aufgaben und Systeme in den meisten massiv parallelen Rechenbereichen vor, wie Wettervorhersage, Kernphysik, Suchmaschinen usw.

In jüngster Zeit stehen wir vor einem neuen Wandel in der Computerphilosophie, der durch die Weiterentwicklung neuer Hardwarearchitekturen und noch besserer Leistung verursacht wird. Die Multi-Core-Architektur wird in naher Zukunft zur vorherrschenden Technologie werden.

Was können wir tun, um davon zu profitieren? In diesem Artikel geht es um eine der möglichen Lösungen, die wir haben können.

Das vorgeschlagene Rechenmodell (mit dem Namen „Object Flow Model“) liefert auch einige Antworten auf Fragen, die in der bekannten veröffentlichten Arbeit von Berkeley [1] aufgeworfen wurden. Hier ist eine kurze Liste der Vorteile, die mit diesem Modell erreicht werden können:

· Einfacher Programmiervorgang und weitere Wartung

· Natürliche OPU (CPU)-Integration und -Migration, wenn Objektverarbeitungseinheiten (OPUs) im Handumdrehen hinzugefügt oder entfernt werden können

· Automatischer Lastausgleich

· Keine Synchronisierung zwischen Aufgabenteilen erforderlich

· Wenig oder keine gegenseitige Sperrung auf Systemebene

Alle diese Eigenschaften sind in der Parallel JavaScript Machine (PJM) implementiert, die weiter unten in diesem Dokument beschrieben wird. PJM kann als Mini-Betriebssystem wahrgenommen werden, das mehrere JavaScript-Aufgaben, mehrere Benutzer und mehrere Front-End-Konsolen steuert.

Einführung
Das Hauptziel von PJM (OS) besteht darin, die parallele Programmierung durch die Einführung spezieller Anweisungen (Hinweise) zu vereinfachen, die durch speziell gestaltete Kommentare in Form von //#pragma dargestellt werden.

Die Parallel JavaScript Machine verwendet NodeJS und ist als Webserver für das Frontend sowie als Server für die OPUs implementiert, die tatsächlich die parallele Ausführung von Code übernehmen. OPUs sind kleine JavaScript-Netzwerk-Clients, die ebenfalls in NodeJS implementiert sind. Es können so viele wie nötig vorhanden sein, die entweder lokal oder remote mit dem Haupt-Parallelmaschinenserver verbunden sind. Die Gesamtleistung der Parallelverarbeitung hängt stark von der Anzahl der angeschlossenen OPUs ab.

Alle zusammenarbeitenden Systemteile können als Mini-Betriebssystem verstanden werden, das die laufenden JavaScript-Aufgaben startet und analysiert, ihre Blöcke in die Systemausführungswarteschlange stellt und eine Art kooperatives Multitasking zwischen ausgewählten Blöcken bereitstellt. Die Berechnungsergebnisse werden auf der Konsole des Web-Clients gedruckt, indem die console.log-Ausgabe von OPUs über den Hauptserver weitergeleitet wird. Jede OPU ist ihrer eigenen CPU (lokal oder remote) zugeordnet und arbeitet über einen einfachen Round-Robin-Scheduler (wird später erklärt). Dies wird durch die Verwendung des PM2-Prozessmanager-Knotenmoduls erreicht.

„Obwohl die Kompatibilität mit alten Binärdateien und C-Programmen für die Industrie wertvoll ist und einige Forscher versuchen, Multicore-Produktplänen zum Erfolg zu verhelfen, haben wir uns mutigere Gedanken gemacht. Unser Ziel ist es, Tausende von Prozessoren zu realisieren…“[1] nicht unbedingt auf dem einzelnen physischen Computer, sondern im gesamten Netzwerk, alles orchestriert von der zentralen Servereinheit. Aus Systemsicht arbeiten alle CPUs/OPUs über ein internes Netzwerk-Socket-Protokoll, das keinen Unterschied zwischen lokalen und Remote-CPUs macht. Der Server (PJM) und die Clients (OPUs) – alle in JavaScript geschrieben, daher ist es [noch] nicht mit C-Binärdateien kompatibel.

Alle parallelen Programme, die in PJM ausgeführt werden, dürfen keine ES6-JavaScript-Erweiterungen verwenden (müssen ES5 verwenden). An dieser Stelle muss darauf hingewiesen werden, dass Erweiterungen wie classes, Pfeilfunktionen, lets und consts und insbesondere async/await kaum parallelisierbar sind und eine gründlichere Untersuchung der JavaScript-Interna erfordern. Aus diesem Grund läuft PJM auf NodeJS V8.2.1. Alle Knotenmodule sind für eine bessere Leistung und Klarheit der Konzepte an diese Version gebunden.

PJM wird gesteuert und Aufgaben werden über die Webkonsole ausgeführt, die sich unter http://parallel-js.net:8888 befindet. Und so sieht es normalerweise aus:

Die Webkonsole wird mit dem ExtJS-Framework geschrieben und über das HTTP-NodeJS-Modul express.js mit dem PJM-Server verbunden. Ein weiterer Teil der Webkonsole (Konsole und Nachrichten genannt) ist über WebSockets verbunden. Hier kommen die Ausgaben und Systemmeldungen aller Programme in Echtzeit an. Es ist wichtig zu wissen, dass in der Webkonsole keine echten Berechnungen durchgeführt werden – alle Berechnungen werden auf dem PJM-Server und den OPUs durchgeführt.

…

Wenn Sie an diesem Projekt interessiert sind, finden Sie den vollständigen Artikel hier.

Der Quellcode für dieses Projekt ist hier.