MorpheusTM – Code and Data Transformer
Morpheus is a platform that allows Essence tools and applications to run on existing operating systems like MacOS, with Android, iOS, tvOS, WatchOS, Linux,, and Windows versions coming in 2021 and 2022.
Whether applying fixed legacy code (packaged as Powers) or code generated by the Essence Agent, this Skill brings a powerful capability to efficiently apply transforms (e.g. AI/ML algorithms and more) to any signal or data in real-time, without the need to write code.
Morpheus can transform existing programming jobs into tiny algorithmic units. Examples might include identifying a search pattern, processing a mathematical formula, a file seek and read, and the reordering of data.
Each of these algorithmic units can be expressed in different code templates that produce different machine instructions. Each of these instructions can be bundled and profiled for timing, for energy use, and for resource use and then separated to run on different processor cores based on scheduling access to changes in data.
While some workloads, such as banking transaction processing, are intrinsically serial in nature, the latencies associated with the reading of caches, disk I/O, network packets, and other events can make it possible to split up the work for better performance in many cases.
Some tasks, such as image rendering, sound rendering, and shape generation are inherently optimal for parallel processing. Other tasks such as searching for data patterns, sorting, running mathematical formulas, and logical decisions of a container of data, simulations, and synchronizing precisely timed changes amongst machines can also be parallelized easily. This parallelization can be accomplished using a transform that allows all cores to run simultaneously (or go to sleep if idle) by transforming workloads into algorithmic units and scheduling their instructions across multiple computing processors.
While some tasks inherently have delays, stalls or bottlenecks, the use of tiny algorithmic units maximizes performance with self-profiling and avoids the semaphore, mutex, or locking mechanisms that affect performance in many other parallel systems. This approach to handling work processing requires all work to be done, which is defined as any computational task expressed in the semantic units of Essence Elements, to be estimated for worst, average, and/or best-case duration and resource usage.
The methods used can be mappings between the Essence Elements and instruction blocks, such as: “iterate all elements in Collection A, for each element consider its value B, if it matches C, then add counter D”.
In English, a phrase like: “tell me who I know in Zaire” or “Please show me anyone in my contacts who resides in Zaire”, will map to “Iterate all people in Contacts, Facebook Friends, and LinkedINConnects, and then for each person, if their residence is Zaire, add that person to the collection named ‘People of Zaire’ and then display ‘People of Zaire’ “.
While it is a simple example, it displays each expansion of a basic term into known resources, with a most-recently-stored value for a range (such as the last time we read Facebook Friend List, it was 1000) and iterating per person, using the btree-iterate approach.
So, the code used is determined for data-access, iteration-of-data, and operations on data (compare it to “Zaire” in this case, which might be GPS-distance or name match or any other method).
These task histories can form an address that can reside in RAM until the space is needed for something else. If RAM space is needed, the data can be cached to disk or dropped and recreated as needed.
These task histories can store the combination of Semantic-Units (the template of activity, such as iterate, compare, find, add) with DataCraft (which databases, which pieces of info used by the Semantic part) and Algorithmic Units.
Algorithmic units identify which actual algorithms and data-reformatting-is needed and was selected, such as using a linear iteration of consecutive addresses (array partition), an incremental pointer de-referencing (a doubly-linked-list), a hash-table, or tree/graph format, etc), which are generally governed by a top-level ‘code-choice’, a midlevel ‘data-format’ (XYZXYZXYZ or XXX YYY ZZZ), and low-level machine instructions (LD, LD, TST, JNE, etc.).
As each task history grows in Data-Craft and Algorithmic Unit histories, the probabilities of making future choices shift based on the accuracy of estimation and the number of optional choices that remain.
For some operations such as square root, there are 2 single-instructions and 4 multi-instruction methods to approximate the value, which is only 6 choices for low precision and only 2 choices for high-precision – a simple case because little variation is possible outside of reordering when the calculation is issued in the task pipeline.
Other cases can be far more complex and have many more expressible choices, which means it may take longer to reach a locally optimal state. Regardless of how much task history data exists, all current tasks are assigned priorities and sorted by resources. We use the classic and effective ‘greedy-solution’ to this NP-complete task, often called the knapsack or traveling salesman problem.
Any delays or missed durations are relayed to the user as required by semantic-unit scope (such as tell me if late, ignore, or log).
It is notable that processor selection alters the Algorithm Unit selection since different instructions may or may not be available as well as accessible ranges of memory usable. It simply results in certain task history scores being set as negative to indicate not applicable.
This approach can have several layers of simulated annealing solutions to the N-tasks using P-processors with I-instructions on R-resources problem. This approach relies on computations being expressed by the Essence Agent.