| … | … | @@ -5,13 +5,13 @@ Experimental effort to enable I/O between Atomese and SIMD compute |
| 5 | 5 | resources. The primary target is commodity GPUs, running either OpenCL |
| 6 | 6 | or CUDA. The current prototype accesses the hardware at a low level, |
| 7 | 7 | working with individual vectors. High-level API's, such as commonly |
| 8 | | used in deep learning, are not supported in this interface layer. |
| 8 | used in deep learning, are not yet supported in this interface layer. |
| 9 | 9 | |
| 10 | 10 | The Experiment |
| 11 | 11 | -------------- |
| 12 | 12 | The experiment, as it is currently evolving, is to understand graph |
| 13 | 13 | rewriting between "natural" descriptions of compute systems. For |
| 14 | | example, the "natural" description of a deep learning transformer is |
| 14 | example, the "natural" description of a deep learning transformer is as |
| 15 | 15 | a kind of wiring diagram, indicating where data flows. By contrast, the |
| 16 | 16 | "natural" description of GPU compute kernels are C/C++ function |
| 17 | 17 | prototypes. How can one perform the rewrite from the high-level |
| … | … | @@ -26,18 +26,18 @@ accepts C++ code and issues machine assembly code. A Java compiler |
| 26 | 26 | accepts Java and issues Java bytecode. The goal here is to accept |
| 27 | 27 | high-level functional descriptions, such as that of a transformer, and |
| 28 | 28 | to generate low-level invocations of GPU kernels. However, the project |
| 29 | | here is not meant to be a "compiler" per se; if that is what one really |
| 30 | | wanted, one could just brute-force write one (or use PyTorch, |
| 29 | here is not meant to just be a "compiler" per se; if that is what one |
| 30 | really wanted, one could just brute-force write one (or use PyTorch, |
| 31 | 31 | TensorFlow, ...) Instead, this is meant to be an exploration of graph |
| 32 | | rewriting in general, and the GPU target just happens to be a realistic |
| 33 | | and suitably complicated example target. |
| 32 | rewriting in general, and it uses the GPU target as a realistic and |
| 33 | suitably complicated example system. |
| 34 | 34 | |
| 35 | 35 | A different way of thinking of this experiment is as an exploration of |
| 36 | 36 | the agency of sensori-motor systems. The GPU is a "thing out there" that |
| 37 | 37 | can be manipulated by an agent to "do things". How does an agent |
| 38 | 38 | perceive the "thing out there", and "understand" it's properties? |
| 39 | 39 | How can the agent control the "thing out there", and perform actions |
| 40 | | on it? To extert motor control on that "thing out there"? How does |
| 40 | on it? To exert motor control on that "thing out there"? How does |
| 41 | 41 | the agent perceive the results of those motor actions? |
| 42 | 42 | |
| 43 | 43 | In the present experiment, the "agent" is is a collection of graphs |
| … | … | @@ -45,17 +45,17 @@ In the present experiment, the "agent" is is a collection of graphs |
| 45 | 45 | [Atomese](https://wiki.opencog.org/w/Atomese), |
| 46 | 46 | and "living" in the OpenCog |
| 47 | 47 | [AtomSpace](https://github.com/opencog/atomspace). |
| 48 | | Thhe subjective inner form of the agent is a world-model, consisting of |
| 48 | The subjective inner form of the agent is a world-model, consisting of |
| 49 | 49 | abstractions derived from sensory perceptions of the external world, and |
| 50 | 50 | the knowledge of a set of motor actions that can be performed to alter |
| 51 | 51 | the state of the external world. The agent itself is represented in |
| 52 | 52 | Atomese; the GPU is a part of the external world, to be manipulated. |
| 53 | 53 | |
| 54 | 54 | An important part of the challenge is understanding how assembly, and |
| 55 | | sepcifically, how self-assembly works. That is, the agent is meant to |
| 55 | specifically, how self-assembly works. That is, the agent is meant to |
| 56 | 56 | be a collection of pieces-parts, a collection of transformation rules. |
| 57 | 57 | These rules are to be assembled to "get things done". The assembly is |
| 58 | | meant to be self-assembly, and is preseumed to live at the edge of a |
| 58 | meant to be self-assembly, and is presumed to live at the edge of a |
| 59 | 59 | critical phase transition. The phrase "critical phase transition" is |
| 60 | 60 | meant to invoke the conventional idea of a critical phase transition, |
| 61 | 61 | such as that seen in Per Bak's critical sandpile. The difference here |
| … | … | @@ -75,9 +75,9 @@ hypergraph database. It has a variety of different ways of talking to |
| 75 | 75 | external subsystems. These were developed to solve various practical |
| 76 | 76 | application issues that arose in the use of Atomese. These subsystem |
| 77 | 77 | interfaces are "well designed", in that they solve the particular issue |
| 78 | | that arose. Human progammers have used them to construct various kinds |
| 78 | that arose. Human programmers have used them to construct various kinds |
| 79 | 79 | of systems. However, these interfaces lack what is needed for a |
| 80 | | dyanmical, sensori-motor, agential point of view. |
| 80 | dynamical, sensori-motor, agential point of view. |
| 81 | 81 | |
| 82 | 82 | These external subsystem interfaces include: |
| 83 | 83 | |
| … | … | @@ -103,8 +103,8 @@ These external subsystem interfaces include: |
| 103 | 103 | These can be found in old, archived |
| 104 | 104 | [github repos](https://github.com/opencog/), scrolling down to |
| 105 | 105 | the oldest repos having no activity. There's also a collection |
| 106 | | of youtube videos showing these in operation; seee e.g. the |
| 107 | | [Virtual Dog](https://www.youtube.com/watch?v=FEmpGRLwbqE) demo, |
| 106 | of youtube videos showing these in operation; see e.g. the |
| 107 | [Virtual AI Dog](https://www.youtube.com/watch?v=FEmpGRLwbqE) demo, |
| 108 | 108 | and, of course, the Hanson Robotics Sophia demos. |
| 109 | 109 | |
| 110 | 110 | The above "work", and provide Atomese interfaces to the described |
| … | … | @@ -130,7 +130,7 @@ introspective interface definition systems. These include: |
| 130 | 130 | to work with external devices. |
| 131 | 131 | |
| 132 | 132 | This project uses the [Sensory](https://github.com/opencog/sensory) |
| 133 | | system to provide the underlysing framework. |
| 133 | system to provide the underlying framework. |
| 134 | 134 | |
| 135 | 135 | Status |
| 136 | 136 | ------ |
| … | … | @@ -217,3 +217,5 @@ similar to above; it performs a simple vector multiply. |
| 217 | 217 | |
| 218 | 218 | The `run-flow-vec` executable is a rework of above, to more clearly |
| 219 | 219 | define and prototype the distinct steps needed to flow data. |
| 220 | |
| 221 | ---- |