| Actor-based programming really interests me. The concepts behind erlang and smalltalk seem to be the closest to an ideal model for the amount of distributed computing power we have today. It seems like we should be able to formalize a generic meta-programming language that describes discrete components. 'actors' would be concepts close to functions that receive inputs and return outputs, everything inside would be generally considered synchronous. These actors speak to other actors via addresses. That idea was all outlined by alan kay. Furthermore, these actors can live anywhere. They can be running on a single CPU, live across multiple threads, cores, processors. Ideally you just throw more processors or remove processors from the mix and the system distributes. Where the rubber meets the road is all the communication mediums. The lowest abstraction is your actor return address is a stack pointer. The highest is the return address is another system (what we currently do with RESTful communications). Once all the inter-actor controls are sorted out, there would need to be a system of dynamic resource distribution. The profiler/scheduler should be able to identify things like
- this actor is handling 85% of traffic, distribute the actor to 6 cores
- the cost of the route from a core to a core on the same processor is X, the cost of the route to a core across a network is Y
- distribute actors that have the most cross communication as closely as possible
- payload size would also need to come into account on top of that, tooling that identifies workload-specific needs could also be identified:
- this set of actors should be considered critical and available on % processors
- take into account things like inter-region availability. A lot of these concepts have already been hashed out and you notice the parallels to things like network architecture. Ideally in the end a 'system' would simply be a pool of usable resources e.g. SYSTEM1: my laptop, an AWS server, my phone, my watch. Computation work is unevenly distributed to the system based on route costs, computational power...even storage capabilities and peripheral access (printers, cameras, etc). A new actor would get initialized in the network and it could be scheduled on your desktop or your tablet. Eventually your system would just become an amorphous workload. My desktop might begin distributing subsets of things that currently run locally to my AWS server because it's closer to the public API i'm accessing.
If actors were generic enough they might be identified and made a reusable pool for multiple applications. Sorry for the stream of consciousness. |
It's not that simple. Objects that can assume locality are written differently than those that can't. The optimize for fate sharing, low latency, etc. If you have just have a mesh of floating objects, you must remove all of those optimizations.