If HTM is going to scale we need to be thinking about distributing the computation among many nodes. Since a lot of HTM is about time sequences, we can’t reliably think of the many nodes as a single neocortex. We need to think of ways to efficiently transfer information which may be out of date between HTM nodes.
Continuing to take the biological approach, does that mean we should start thinking about and studying human society and collaboration, culture and language? Or can we stay more low-level and think about passing SDR sequences back and forth?
I’ve been working on a slightly related idea, where two equally dimensioned HTM regions can produce “offspring” who take a random 50% of all dendrites from each parent, thus starting primed with inherited memory from both parents.
This might be extended by letting systems swap some configurable percentage of dendrites in an exchange (thus gaining some new knowledge at the cost of slightly degrading their current knowledge). This is clearly not a biologically plausible approach though
BTW, I am assuming here that you are thinking of distinct “creatures” (i.e. not part of a single “creature”). If the goal is hooking up distinct parts of a single “brain”, I have some better ideas for that.
I’m mainly talking about implementing HTM in a scalable way that could run over a distributed network in the cloud. Although I think it’s a bit early to start thinking about these things…
I am currently working on this type of distributed HTM implementation (writing it in Go). I posted some of the original ideas a while back on this thread. You make a good point about nodes being out of date though. My strategy assumes HA. It definitely might be worth thinking about some type of functionality where if a node is late, it can still get back into the game, rather than just being dropped or skipping one or more timesteps.
You can certainly imagine layers running on different compute nodes, passing SDRs between each other. Layers would need to communicate laterally between each other in parallel, also via SDR. Oscillations might arise naturally in a medium like this.
One thought I had (in a sharding-based implementation) would be that say 75% of each node’s capacity is dedicated to managing its own minicolumns or cells, and 25% is allocated to managing minicolumns or cells that other nodes are primarily responsible for. (of course this would need to be 50%/ 50% for full coverage – I’m assuming some noise is acceptable)
Then when nodes randomly go down around the network for a few timesteps, the redundancy built into the other nodes can pick up the slack. When they come back online, they can be brought up to speed and get back into the game.
Communication between nodes of synapses and permanence values could be avoided by having a shared strategy for random seeds. That way, two nodes responsible for the same cell could independently form the exact same random connections to other cells during TM, for example.
Another possible way to distribute an AI is to run several instances of the same AI on threads. All instances of the AI share the synapses and associated data. When an instance of the AI learns it updates the shared data. This allows a single AI to gather more experience, and faster.
I first saw this method in reference to deep learning AIs. In that application, they’d managed to perform learning updates without mutex locks on their shared data. Multithreading without synchronization is possible because the worst that can happen is that some learning updates are overwritten, which is an acceptable loss, expecially considering: the cost of mutex locks, that this is not a frequent event, and the gains from having numerous threads gathering experience.
