I am trying to convert a simple program that uses coarrays and events to one that relies on FEATS. The question I ran into is:
My graph of tasks is simple, task 1 reads a line from a file and passes this to task 2, task 2 converts it into uppercase and passes it on to task 3. In the meantime task 1 reads the next line and so on. It uses the events fature to synchronise the tasks
However, I wonder how the loop should be implemented: via a call to “run” in an explicit loop? Right now, each task uses its own loop and the synchronisation is very deliberate. It woud be nice to see this taken care of the FEATS framework.
Hi Arjen, as the main author of FEATS I’m sorry to say haven’t had much time to work on it, and probably won’t for some time in the future.
That said, do you know ahead of time how many lines are in the file? If so you could write a loop to construct the whole task graph before calling run. The matrix factorization example does this. You can find a bit more description of the example in the paper. FEATS wasn’t really designed for use cases where you don’t know the whole graph ahead of time. You can certainly construct and run one graph after another, but the execution of their tasks won’t be overlapped.
Additionally, writing and using FEATS are great exercises in learning parallel programming, but my final conclusion was that there probably aren’t many applications where the approach is actually performant (at least as currently written). It’s really only good for cases where each task has a lot of computation and the amount of communication needed between them is small, otherwise the communication and overhead of the scheduling really dominate.
Hi Brad, ah, that explains it . My program is just a demonstration of how you could use events to coordinate tasks. I was thinking of something like two or more big tasks where onest task provides information for the next and can continue with the next bit of work as soon as the result has been passed on. More concretely, in my typical application field: a hydrodynamic model doing one time step after which the flow field is passed on to a water quality model.
In that particular case, the number of tasks is known in advance, but that is not a general situation, I’d say. Still, it is intriguing to see what can be done.
. My program is just a demonstration of how you could use events to coordinate tasks. I was thinking of something like two or more big tasks where onest task provides information for the next and can continue with the next bit of work as soon as the result has been passed on. More concretely, in my typical application field: a hydrodynamic model doing one time step after which the flow field is passed on to a water quality model.