📚 Calculations

The Thinker™ has been designed in assumption that runtime computing structure is complex and heterogeneous. A GPU-like equipment seems ineffective here, because it targets calculation of same kernel software by thousands of arithmetic cores simultaneously. Instead, a project in the Thinker can contain thousands of different functions each computed in their local area of the network. Very possibly such design could perform well with FPGA hardware acceleration.

Nevertheless, the program promises to process data in virtually parallel way. Strictly speaking, exactly parallel computation isn't possible on contemporary CPU hardware. Pieces of software code go by its own schedule to available computing cores, passing through optimization schemas and multi-level caches. Computed numbers return back to main memory same road back. This is a very complicated process upon close examination.

As the Thinker is a Java¹ application, its parallel computation is based on ExecutorService technology of the language. It allows to use as much virtual processors as needed. A ratio of available math hardware cores versus number of active threads determines a degree of parallelism at runtime. Some processes are supposed to run in parallel, while other stay in a queue while waiting for available hardware.

The Thinker runtime design always has a default ExecutorService available. In addition, a model can include as much separate services as needed (named in a model as "processors"), for any part of design hierarchy. Both main and supplement processors have service execution controls. An assigned Java service can run (restart) computations, be paused and completely stopped. All supplement processors are managed independently. Controls for the main processor manage entire set of processors. So do controls for the project, in a scope of its own contents.

Every Thinker processor operates in a manner² reminiscent of being served by a restaurant waiter. It accepts "orders" from dedicated computing points, puts them in a queue, and returns result in an order of completion. This standard policy can be modified when a default processor class is in use. Orders may naturally appear duplicated in the queue. Processor settings allow to collapse same orders into one till a different order is met. Or all duplicated orders can be dropped from the whole queue. These deviations can dramatically improve performance when such policy is acceptable by the logic of the model. Another feature allows to delay a moment of actual processing until a specific event occurs: timeout elapses or queue accumulates enough orders. It allows to compensate desynchronized arrival of values to arguments of the function that is a regular occurrence in practice.

Desktop variant of the Thinker builds runtime model with all elements being observable. When a particular element obtains a new value or changes its status, all listeners of the element will get this update immediately. A timeline frame in the Analyzer tab and Properties pop-up window are examples of such listeners. For a special application cases, the Thinker can generate runtime model which isn't observable, for the purpose of total processing performance. Anyway, this model still can interact with outside world via custom Java classes attached to a field element.

Notes:

1. Software version 2.X is built with Java version 15 SDK that is mainly a restriction inherited from Neo4j database version in use.
2. EU patent pending.