Couple of thoughts/observations:
- Erlang has a vm, so that would avoid building a vm.
On the downside, erlang is not pure: the message-passing and the io:
commands imply the possibility of side-effects.
Still, it could be good enough for a proof-of-concept?
- implementation as a library function?
Instead of building/modifying a vm to re-implement how map works,
perhaps an easy way of doing this would be to create a new map
function (dpmap? (=Dynamic parallel map), which chats to a scheduler
process, which decides whether to split the map or not.
Downside: constant overhead for all maps, even really small ones that
would otherwise run really fast, and will ultimately be assigned only
a single process anyway.
(note: using erlang terminology here, where "process" means
essentially "thread").
Of course, even modifying the vm to parallelize maps etc would have a
constant overhead, but possibly the overhead could be much smaller if
implemented directly in a vm?
Possibly an approach could be:
- impliment as a new dpmap library function
- someone could optimize this in a vm later