Distributed HTM?

I have dabbled with Thesbian, which is an agent based environment in Python. I did wonder about how nupic HTM might be distributed and the use of agent based concurrency made some sense? I note an amalgam of nupic and torch. What about ray.io? Is it too soon to dream?

Cheers,
A

5 Likes

A year and a half ago, I’d done some work starting an HTM implementation in Elixir, where each column acts as an agent sending messages around in a pool.

Seeing as how we’ve been given some time here, I’ve been dusting that off and looking at revamping it as a web API.

I’ll resurrect my old thread in the morning and bring my repo online.

Be well.

IMO it would be interesting to see topology implemented in a distributed manner.

2 Likes

From my experience. Running a single HTM layer on multiple systems is likely a very bad idea. HTM is entirely bounded by the memory bandwidth available to it. Having a distributed system to process a HTM layer is going to drastically decease the effective bandwidth due to communication latency and networks are just slow compare to DRAM.

On the other hand, distributing HTM to multiple systems sounds promising. And is a a planned feature of my HTM library. But I didn’t got around to build it nor have a piratical use. It could be useful to scale 1k brain theory to human scale. But we need a fully working TBT theory before that.

It doesn’t make sense to distribute the same task (htm layer) in multiple distributed units. At least in the perspective of distributed computing. If distributed computing is used in HTM I would recommend using decoupled tasks that can be run independently in distributed units, therefore drastically minimizing communication between units. Communication is only done ideally during aggregation of results.

Currently, the topology looks like this:

server–> pool manager --> columns.

Each part is its own process, using the BEAM VM’s concept of lighweight threads. Each process holds its own state, and communicates with others via messaging. This allows each column to act as an independent entity, which makes modelling a bit easier. Where Elixir is built on top of Erlang, and Erlang’s BEAM VM already includes the ability to scale and distribute work across hosts, reducing the amount of engineering we’d have to do. The VM automatically distributes processes across all the cores in a system, and across the hosts whenever a new node is added.

Current process flow:

Step one:
encoder(s) ---- SDR —> pool —(broadcast message)–> column(s); check overlaps and predictive state

Step two:
pool <—(connection count messages)— column(s)

Step three:
pool —(to winners)—> column(s): strengthen overlap connections; if in predictive state, strengthen. If not, burst.

Step four:
Update pool state, so that it is able to be queried from remote host

Planned expansions: remote callbacks for “IO block system” (state machine which amplifies/dampens pool’s connections to IO block depending on current state, whose parameters can be configurable).

Intended use is for writing controllers for simulators, where controller would encode simulator conditions and send SDRs to pool server, which would then asynchronously send a callback with output data. Using this model, could even connect to robotics projects using something like ESP32 or its cousins for real world experiments.

Anyway, had actual work come in yesterday afternoon, which might throw back my repo setup just a bit. I’ll revive that old thread when I get my code up.

2 Likes