Let's delve deeper into the intricate world of AGI's technological base as we explore where AGI is most in demand: mobile autonomous systems (we started in AGI: WHAT IT MAY LOOK LIKE). These systems, encompassing robots, autonomous driving systems for cars, and drones of various types and purposes, pose unique challenges that we'll unravel in this discussion.
The autonomy of such systems and the reaction speed required for practical use dictate the need to avoid remote data processing. This, in turn, means the need to make the most efficient use of local computing resources.
The cornerstone of this technological foundation is undoubtedly multiprocessor computers with substantial memory capacities. The ability to perform parallel calculations and store a vast amount of current information in RAM is what enables the required reactivity of the AGI system, allowing it to respond swiftly to events.
The use of multiprocessor systems is not something new, but AGI has quite clearly defined specifics. Unlike non-specialized systems, where several processors are used simultaneously by many independent applications, each of which uses its own part of the RAM, a specialized AGI system uses all resources within one very complex application. Many logical processes (processing sensory information from many sensors, generating a description of the current situation, generation a forecast of changes in the situation, assessing the state of the AGI system itself, long-term and short-term planning of actions, monitoring the implementation of planned actions) coexist within one application. Accordingly, the complexity of coordinating the actions of subsystems within a single AGI system increases significantly, including the need to switch between different operating modes ("quiet" normal, stress, emergency when part of the sensors or actuators fails, etc.).
The currently widespread software architecture for robots, where functional modules exchange data with each other, is not an acceptable option if the number of modules is large. The number of logical relationships grows quadratically with the number of modules, the analysis of relationships becomes more complicated, and the infrastructure for supporting data exchange between modules consumes a significant share of computing resources. The growing complexity of interconnection analysis results in difficult-to-detect cyclic dependencies, observable in the form of random deadlocks and/or radical slowdowns of processes, as well as the complexity of debugging the system, significantly when its various modules are developed/modified in parallel by different programmers, who must take into account the specifics of the modules being developed by others.
The solution lies in embracing an alternative structure, where all components of the AGI system are divided into passive data modules and active modules that process this data. This approach makes the data processing modules independent of each other, enhancing the system's efficiency and adaptability. Such an architecture also makes it possible to implement a standard mechanism for coordinating access to shared data, providing exclusive access to data for its modification and simultaneous access by the several modules that process data without modifying it (read access). Such a single mechanism makes it possible to exclude explicit mention of synchronization and multithreading in the code of active modules and, accordingly, allows them to be developed by specialists in the relevant field without studying all the details of synchronization and multithreading programming. See AGI: EVENT DRIVEN ARCHITECTURE and AGI: MULTICORE AND MULTITHREADING for more details.
Those who are familiar with the developments of "old good" AI systems will see an analogy with blackboard AI architecture in this approach. The analogy with the organization of work of a regular library, which does not require interaction between readers, is also obvious. This architecture radically simplifies both development and modification: replacing an active module with an alternative or modified version (sometimes even eliminating the module) does not require modification of other components.
The complexity of an AGI system also requires the presence of an analog of the traditional telemetry subsystem for complex embodied technical systems. This subsystem collects and stores information about the operation of software components, allowing one to find problems and analyze their performance. Unlike a simpler traditional log file recording system, such a system should summarize the collected data, reducing its volume and making it more convenient for developers to analyze.
The choice of programming language is no less critical. The requirement for maximum efficiency immediately rules out interpreted languages (like Python). The need to integrate modules for very different purposes within a single AGI system (for example, processing visual sensory information and long-term planning using logical inference rules) makes it extremely useful to use existing specialized libraries for their various fields; the only modern programming language that has such a universal set of ready-made tools is C/C++. The powerful support for generic programming in C++ makes alternative options even less attractive. Finally, the need for cross-platforming, including for use on specialized hardware, makes the choice in favor of C/C++ essentially the only option.