[saga-rg] Task model...

[John Shalf]

I agree with nearly all of Thilo's comments on this subject.

On Oct 28, 2005, at 9:06 PM, Andre Merzky wrote:
> Questions:
>
>    Q1) any comments to the Boston discussion?  I hope I reflected that
>        correctly...
>    Q2) are there any drawbacks by introducing 4a or 4b, apart from the
>        additional number of calls?

I think it is good. (go for it)

>    Q3) Are the advantages (simplicity for most usages, powerfull for
>        bulk operations and others) good enough to introduce 4a or 4b?

We want a more concise way of describing async operations, so this is  
good.

>    Q4) You like 4a or 4b better?

I do not like 4b.  The flags seem very klunky.  I think the naming of  
the method call is a more effective means of communicating its  
function (it is certainly more readable than code that uses the  
flags).  Readability is very important.

>    Q5) Any comments to 4a1, 4a2 or 4a3? (not part of the Strawman!)

I prefer 4a1 because it is more readable and the implementation would  
be quite straightforward. It is also a familiar paradigm for any MPI  
programmers and anyone who has played with various proprietary Async  
I/O implementations. (its a very familiar and conventional approach)

I kind of like 4a2 as well from the standpoint of a C++ programmer  
(even with Andre's syntax corrections).  However, the resulting  
bindings will not be very consistent with the approach we would take  
for Fortran or C bindings (eg. those would likely look more like  
4a1). It is not really much more readable than 4a1.  Therefore, I'm  
uncertain if it is worth fragmenting our approach to bindings in  
different languages when there is not a clear benefit in terms of  
readability or implementation complexity.

I do a lot of C++ programming, but I find the 4a3 option a bit  
obscure both in terms of readability and any advantages it might  
confer in terms of implementation.  It would certainly be easier to  
create multi-language bindings for a single code base if we stick  
with something more conventional like 4a1.

Each approach is equally readable to me (less so for 4a3).  I'm  
certainly open to any additional information on how the 4a2 and 4a3  
approaches could simplify implementation.  If the other approaches  
can offer some implementation benefits, then maybe I'd give them  
extra consideration, but otherwise, I would prefer a more  
conventional approach like 4a1.  The only implementation I'm outright  
against is the 4b example.


-john