(Task-based system) The task model heavily resemble's llbuild2fx's FXKey, computeValue and fi.request mechanism.
(Memmory model) llbuild2fx has a closer relationship with CAS for storage/memory. Legion's emphasis is on logical region (as an abstraction over memory) and Rect (to express the shape/dimensions of the computation).
(Decoupling the task from underbelly of compute) Legion has the following API
Runtime::preregister_task_variant<int, sum_task>(registrar, "sum", AUTO_GENERATE_ID);andregistrar.add_constraint(ProcessorConstraint(Processor::LOC_PROC));
that resemble FXAction and FXExecutor in llbuild2fx.
- llbuild2fx can be coupled with AWS-lambda style compute, but does not maintain a pool of workers itself. You have to wire it up to a compute engine via providing your own
FXExecutorimplementation. - Legion relies on GASNet (see tutorial). I've never worked with GASNet but I'm guessing it is some sort of gRPC (+ a unified memory address space over network) that supercomputers use. I found this talk on YouTube that describes GASNet.
Watch Alex Aiken hinting at compositional advantages of task-based systems.
- Workflows are task-based systems at a much coarser granularity (How to compose parallel software together)
- Task graphs are naturally compositional
- The composition of Task-based libraries (example from Tensor Algebra)
To get a good sense of Legion's API and with a simple but non-trivial example, start with this link.