Author: Vladas Saulis, PE Prodata, Klaipėda, Lithuania

May 18th, 2024

Abstract
This paper presents a new programming model that can utilize multi-core CPU systems in a simple and auto-balanced way. This model also proposes an easier programming paradigm for developing parallel tasks and systems in most massively parallel computation areas, such as weather prediction, nuclear physics, search engines, etc.

In recent times we are facing a new shift in computing philosophy, caused by advance of new hardware architecture and even better performance. Multi-core architecture will become prevailing technology in the near future.

What can we do in order to take advantage of this? This paper is about one of the possible solutions we can have.

The proposed computing model (which is named “Object Flow Model”) also provides some answers to questions raised in the well-known published paper form Berkeley [1]. Here is a short list of advantages that can be reached using this model:

· Simple programming process and further maintenance

· Natural OPU (CPU) integration and migration when object processing units (OPUs) can be added or removed on the fly

· Automatic load-balancing

· No need for synchronization between task parts

· Little or no mutual locking on the system level

All these characteristics are implemented in the Parallel JavaScript Machine (PJM), which is described below in this document. PJM may be perceived as a mini operation system which controls multiple JavaScript tasks, multiple users and multiple front-end consoles.

Introduction
The main goal of PJM (OS) is to simplify parallel programming by introducing special instructions (hints) that are represented by specifically crafted comments in form of //#pragma .

The Parallel JavaScript Machine uses NodeJS, and is implemented as a Web server for the frontend, as well as a server for the OPUs that really do the parallel execution of code. OPUs are small JavaScript network clients implemented in NodeJS too. There may be as many of them as necessary, connected to the main parallel machine server either locally or remotely. The overall performance of parallel processing strongly depends on the number of connected OPUs.

All system parts, working together, may be understood as a mini-OS which launches and parses the running JavaScript tasks, puts their chunks into system execution queue and provides some kind of cooperative multitasking between selected chunks. The calculation results are printed to the Web client’s console by pipelining console.log output from OPUs through the main server. Every OPU is assigned to its own CPU (local or remote) and works through a simple round-robin scheduler (will be explained later). This is achieved by use of PM2 process manager Node module.

“Although compatibility with old binaries and C programs is valuable to industry, and some researchers are trying to help multicore product plans succeed, we have been thinking bolder thoughts. Our aim is to realize thousands of processors…”[1] not necessary on the single physical computer, but throughout the network, all orchestrated by the central server unit. From the system point of view all CPUs/OPUs are operating via internal network socket protocol which doesn’t make distinction between local and remote CPUs. The server (PJM) and clients (OPUs) — all written in JavaScript, so it’s not compatible with C binaries [yet].

All parallel programs, which are running in PJM, must not be using ES6+ JavaScript extensions (must be using ES5). It’s important to state here that such extensions as classes, arrow functions, lets and consts, and, especially, async/await are hardly parallelizable, requiring more thorough JavaScript internals research. This is why PJM is running on NodeJS V8.2.1. All node modules are locked to this version for better performance and clarity of concepts.

PJM is controlled and tasks are running using Web Console which resides at http://parallel-js.net:8888 . And here is how it usually look like:

The Web Console is written using the ExtJS framework and connected to the PJM server with the use of express.js HTTP NodeJS module. Another part of Web Console (called Console and Messages) is connected using WebSockets. This is where all programs’ output and system messages are coming in real time. It is important to know that no real calculations are performed in the Web Console — all calculations are done on the PJM server and OPUs.

…

If you are interested in this project, please find the full article here.

Source code for this project is here.