Let's add parallelism to the flash evaluator. There are two forms of parallelism I am thinking of:
- Concurrent execution for pipes specifically. There is a problem with the current implementation of pipes for inter-instruction communication: because everything executes serially, pipes can easily fill up. In the program
foo | bar, if foo produces a lot of output, it will deadlock because bar is not yet running to consume that data. So we have to do something to make steps in these pipelines run concurrently.
- General data-flow parallelism. Imagine the program
foo > foo.txt ; bar > bar.txt ; qux foo.txt bar.txt. The foo and bar commands should be able to run in parallel, and qux should run when they're both done. At least at some elevated optimization level, if not by default.
The first is required to make pipes work in general; the second would be nice to have just as another fun optimization that real shells cannot do.
I think we should implement both (in the short and long term, respectively.) Here are some proposed approaches:
- Stick with serial execution, but execute every instruction that produces a pipe as output asynchronously. Instructions that read from pipes as input work normally. This is probably pretty easy to do for
ExecInstr but hard to do for built-in FlatGFA ops.
- Switch to a data-flow-style, parallel-by-default evaluator. You mark all resources as "ready" or "not ready," and mark every instruction as "waiting," "running," or "done." Repeat until all instructions are done: look for instructions whose inputs are ready and launch them. Asynchronously, whenever any instruction finishes, mark its outputs as done. Pipes are marked as done as soon as the instruction launches.
The latter seems complicated but exciting. It should probably be an alternative mode that exists alongside the serial evaluator.
Let's add parallelism to the flash evaluator. There are two forms of parallelism I am thinking of:
foo | bar, iffooproduces a lot of output, it will deadlock becausebaris not yet running to consume that data. So we have to do something to make steps in these pipelines run concurrently.foo > foo.txt ; bar > bar.txt ; qux foo.txt bar.txt. Thefooandbarcommands should be able to run in parallel, andquxshould run when they're both done. At least at some elevated optimization level, if not by default.The first is required to make pipes work in general; the second would be nice to have just as another fun optimization that real shells cannot do.
I think we should implement both (in the short and long term, respectively.) Here are some proposed approaches:
ExecInstrbut hard to do for built-in FlatGFA ops.The latter seems complicated but exciting. It should probably be an alternative mode that exists alongside the serial evaluator.