Hi @Rich_Morin,
A minor note.
This is not the intention of the Thousand Brains Project. If I implied this somehow, then I apologize, that was not my intent.
AFAIK, neither you nor any other TBP member has ever made or supported this claim. However, I’ve made it in several posts and never had any pushback on it before. Since this seems to be a fairly fundamental design issue, I’d like to explore it further.
It seems pretty clear that Monty will not be implemented as a single, monolithic process:
- The basic premise of the TBT is that there are lots of “brains” (i.e., CCs).
- Any useful Monty instance will require a highly concurrent architecture.
- The use of CMP, LMs, and SMs points to a message-passing approach.
- …
All told, this sounds a lot like the actor model to me. In what way(s) is Monty NOT expected to evolve into an Actor-based system? (Please feel free to take this discussion to another thread, as appropriate.)
A post was merged into an existing topic: Platform Current Reality Tree
Hello, everyone. I’m a relatively recent addition to the TBP team and I’m excited to help stabilize and grow the platform. I’ve been writing about, promoting, and building things with the Actor Model for more than 15 years now. TLDR; I don’t believe that actors are a good match for TBP at its current state of development.
Monty models cortical columns in the brain and their surrounding infrastructure. The cortical columns continuously run a sensory-motor learning process similar to an OODA loop. The current Monty implementation is a discrete-time model with no fixed sampling rate. Each time-step is a deterministic data-flow process that integrates current observations with information from the previous step. Outputs from all of the columns are synchronized between columns to provide inputs to the next step. In other words, all the column steps are logically simultaneous, similar to cellular automata. Also, the topology of connections between columns is fixed. Messaging is not ad-hoc.
Within a column’s processing step, there are opportunities for data-parallel computation, perhaps organized into a systolic array. Operations on bulk data, such as transformations of point-clouds, could be accelerated by SIMD processing elements such as GPUs. Regardless of a column’s internal organization, communication among columns and interaction with the environment are synchronized at the boundaries between them. The result may be viewed as an Agent-based Model.
Agents and Actors, although superficially similar, have significant differences. Both are models of communicating entities with individual goals and their own private state. However, actors are driven by arrival of ad-hoc asynchronous events. The topology of their connections evolves dynamically, and they generally don’t interact with a shared environment.
The primitive effects an actor may generate in response to an event are:
-
Create new actors with initial state and behavior
-
Send new message-events to actors they know (including actor addresses)
-
Become a new state and behavior for processing subsequent events
Of these primitive operations, (after initialization) Monty would only use Send and Become, making it equivalent to a data-flow machine. Send would simply carry immutable data, and not make introductions (changing the topology) by passing addresses. Become would be used to mutate the actor’s private state, and possibly the actor’s behavior (to model a state-machine). The discrete-time processing steps and deterministic data-flow do not take advantage of the dynamic properties of actors.
Monty is still a pre-1.0 research project. After the platform becomes stable enough to declare a 1.0 release, we may find value in structuring inter-component communication (e.g.: CMP) along actor-inspired lines. Today is not that day, however I hope to help accelerate the achievement of that milestone.
3 Likes
Thank you for the clear and convincing explanation. AIUI, an agent is a message-based process which is: agentic (e.g., interacts with the motor system), a daemon (i.e., runs on its own), and (always?) communicates via messages. So, not (just) an actor.
Rather than simply responding to incoming messages (like an actor), an agent has an “active inner life”. In the case of Monty’s LMs and SMs, this means that there could be:
- SM messages that indicate the availability of new data
- LM messages that say “try looking over there…”
- …
Given these sorts of inputs, an LM could interact with its SMs and motor / sensor infrastructure, producing hypotheses (e.g., about objects at poses) which are framed as CMP messages.
LMs and SMs already implement a lot of this (e.g., scanning around a visible field, forming hypotheses). However, they aren’t really set up as agents, so some sort of wrapper(s) will be needed.
Discussion
It’s important to clarify whether a design decision was required by biology and/or TBT or whether it is an implementation detail. Here are a few, for discussion…
Dynamic Behavior
Monty’s current design doesn’t support dynamic changes to addressing topology, but (AFAIK) this isn’t baked into either biology or TBT:
-
As the cortex grows, new structural elements (e.g., cortical columns, neurons, synapses) need to be produced. A Monty implementation may need similar capability. If so, the actorish ability to spawn processes could come into play.
-
Even in a developed brain, synapses can be strengthened over time. AIUI, this increases the chance that the target will “get the message” and also lowers the message latency. It seems likely that this strengthening is a critical part of how brains operate.
Note: This behavior could be emulated, at least in part, by a coincidence-detecting LM which told other LMs to subscribe to each others’ published messages (i.e., dynamic Pub/Sub). Sounds like a job for a higher-level LM…
Synchronization
The cortex isn’t synchronous, except (perhaps) for brain waves. So, the strong synchronization seen in the current version of Monty may not be essential or even desirable. More to the point, as Joe Armstrong would have said, it “defies the laws of physics” in any distributed (and most concurrent) systems.
That said, if we wanted to emulate a synchronous system on an asynchronous base (e.g., the BEAM), this isn’t out of the question. Assorted technology (e.g., CRDTs, queues, ring buffers) can be used to smooth out (most) issues of message latency.
Note: Seymour Cray designed the Cray-1 to use color-coded wires of different lengths (and hence, propagation delays). So, signals from a given subsystem always arrive with a constant delay. This sounds a lot like the way that nerve fibers and synapses work, modulo the effects of synapse strengthening, as mentioned above.
Aggregations
Because a single LM can’t do all that much, Monty will need to support aggregations of LMs that work together on tasks. So, we’ll need a way to assemble and run these aggregations.
As a simple example, let’s assume that we want Monty to use multiple cameras to examine a single object. Although one could build a single-LM Monty instance that uses and controls more than one camera, this seems unfaithful to the basic ideas of TBT.
So, imagine that we have multiple Monty LMs, each with associated SMs and motor support. Each one would use and control a single camera, passing “votes” back and forth to establish objects’ position and orientation in a common reference frame.
Of course, there isn’t any essential requirement for all of the players to be LMs. For example, either a human or an LLM might also say “look over there for a logo on this cup”. As long as the receiving LM gets a valid “vote”, it shouldn’t care who sent it…
Concurrency
My impression is that Monty is migrating between a couple of experimental frameworks, but I have no idea of their affordances, approaches, or limitations with respect to concurrency. In particular:
- Does the target framework support concurrent LMs?
- Does it (or Monty) support message-based I/O?
- What scale of aggregations can it support?
I’ve written elsewhere about running Monty instances under Elixir and Pythonx, using the BEAM et al for process dispatch, message handling, etc. I still think this is an interesting possibility; IMHO, it could easily handle the requirements for agents.
In Closing
I agree that it could be a distraction to ask the team to spend (much) time on message handling, given the current (monolithic, synchronous) approach. However, adding a pass-through “CMP tap” (or some such) seems like a potentially useful and fairly modest ask, so I hope it happens sooner rather than later…
Side-note: the only regions that are known to grow neurons post-birth are the hippocampus and the olfactory bulb. In fact, a third-trimester fetus has twice the amount of neurons an adult has. Neurons get pruned down with age. Growth mostly occurs in the form of synapses.
This can be tackled with static-memory I/O buffers without the need for dynamic pub/sub, e.g. an LM could have a pre-determined number of static inputs, available for other LMs to plug into as they see fit and push data to. Similar to how dendritic spines work. If you want max performance, you gotta approach it as “wiring” rather than “messages”.
The problem here is repeatability of benchmarks and debugging. System-wide synchronicity makes it easier to narrow down causes of benchmark changes. You lose that edge if you go async. It will become inevitable at some point to scale and distribute, but since the foundation is not done being poured, I agree with the team that now’s not the right time for async.
2 Likes