I remember the discussion about global asynchronicity in HTM/NuPic using Erlang, someone even tried to implement it I think. Almost six years ago now, there’s probably still a video on Matt’s Twitch channel. Back then no one could answer the question about synchronization mechanism: async removes the single synchronization point, and incoming events stop being strictly sequential, which means we have to start timestamping frames, introducing time buckets, all kinds of additional complexity needed to compensate for it. It’s probably simultaneously somewhat different and somewhat similar in Monty.
But, the main point is: asynchronicity is IO. Training and inference is computation.
This means that asynchronicity can be only ever useful at the seams, and nowhere else. Network, filesystem, IPC. It has its place, it exists to solve a specific issue. And Monty will need to solve that issue if it wants to scale. But using async as a platform is just burning electricity; and it’s also burning human-hours, because asynchronous code introduces its own wealth of cases, which makes code much more complex, not even mentioning refactoring it in the first place. Instead, async needs to be injected into the code. This is how, for example, Zig is aiming to solve this problem: all IO handlers are passed around, just like memory allocators. Benefits are obvious: you can introduce your own, at any moment, whether you want to keep sync or async - everything is in your control. This is especially important during prototyping.
And this is why the reality tree of the Monty project has so many injections. It actually needs more. I also like the way @tslominski keeps bringing it up in his replies; because many of these questions are, in fact, whiteboard questions. When we’re trying to justify introducing this or that technology, or this or that approach, we need to go back to the whiteboard. What does it tell us? What problem are we trying to solve? What do we gain, and what do we lose?