[saga-rg] Task model...

[John Shalf]

On Nov 3, 2005, at 2:01 PM, Hartmut Kaiser wrote:
> Andre Merzky wrote:
>> Quoting [John Shalf] (Nov 02 2005):
>>>
>>>>   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.
>>
>> You favour 4a1.  We think that implementation is very straight  
>> forward
>> for all three versions.  Readability seems not much different to me,
>> and might largely be a matter of taste.

I think the readability is nearly equal for all of 4a1-3.  The  
original statement assumed 4b was still in the mix (and 4b flunks the  
readability test).  I consider 4a3 a bit less readable than the  
former two because the use of the templating syntax there is a little  
obscure (normally only see the <> in constructors/declarations), but  
I agree that is more a matter of taste and not of substance.

> 4a1 is a plain match of some flat API onto the C++ language. It  
> bloats the
> exposed object surface (every function has to be there 3 or 4 times).

I don't think replication of the API constitutes a serious issue so  
long as the function naming convention is regular and consistent.  So  
that is to say that 4a1 does not present a programmer with any  
greater cognitive load than 4a2 for instance.

>>> 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)
>>
>> Well, these are C-API's.  Is there a C++ binding for MPI, and does it
>> look the same?
>
> Frankly, I'm not a specialist here. But from what I can tell from  
> the MPI
> specs the C++ bindings are more or less a complete copy of the  
> underlying C
> API, which is not object oriented (but please correct me if I'm  
> wrong).

Well, the default is to just use the regular C API, but the mpi++  
bindings encapsulate the communicator in the class, but otherwise the  
calls are very similar. Its something like
	comm.iSend(...stuff....)
	comm.Send(...stuff...)
	comm.iRecv(...stuff...)
I think the MPI iSend() vs. bSend() and sSend() is an example where  
the number of different send and recv calls is increased by 4x, but  
quite frankly it doesn't affect the cognitive load for the programmer  
because the naming convention is very regular and consistent.  (eg.  
there really isn't much of a difference between 4a1 and 4a2 in that  
regard).

>>> 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).
>>
>> But, well, that is the idea of the language binding!  I agree that C
>> and Fortran would look more like 4a1, of course.  But that is no
>> reason that C++ should look like that as well, or Java, Perl etc.
>
> 4a2 is good from the standpoint of a C++ language binding but infers
> non-needed objects in the interface (the sync, async and task  
> subobjects)
> additionally for every API object there have to be constructed,  
> initialised
> and destructed these three subobjects. I know, that performance is  
> not an
> issue in the SAGA context, but I think we should avoid premature
> pessimisation (i.e. building on top of a obviously non-optimal  
> solution).

I agree... 4a2 doesn't seem to make the implementation of the  
bindings any easier or more optimal than the flat approach.

>>> 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 think that 4a2/4a3 actually allow nicer implementations, as it
>> allows to have the different async parts somewhat separate from the
>> sync parts.  We think its nicer :-)
>
> 4a3 the only implementation in a C++ like manner I can think of, which
> provides:
> - an interface which conforms to modern C++ concepts pushed by  
> Boost et.al.
> - it avoids not needed overhead if some of the features are not  
> needed/used
> (this gets optimised away by any decent C++ compiler)

Well, if the compiler can actually take advantage of that syntactical  
convention to apply more efficient optimizations, then that is a  
clear advantage to that approach (whether or not I find the syntax  
obscure).

> - it allows for using the SAGA API classes in a generic programming  
> context
> using the execution model as a (template) parameter (I can  
> elaborate on this
> further if needed)
> - minimises the exposed interface
>
> Agreed. Fortran and C bindings probably will end up to be very  
> similar. In
> C++ we should conform to the main C++ language paradigm (i.e. don't  
> pay for
> anything you're not going to use etc.)?
>
>>> 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.
>>
>> The main point really is that the object itself has only the sync
>> method calls, and the async calls can be put into separate
>> header/sources easily, and build (by default) on top of the sync
>> calls.  Of course, you can do that with all three versions, but its
>> not as obvious in 4a1.
>
> It's not a matter of simplifying the implementation, it's a matter of
> simplifying the exposed interface. I even would go for a more complex
> implementation if the interface gets simpler. And from my  
> experience the
> templated syntax isn't counterintuitive if you're used to  
> programming in
> C++.

Its not clear to me that C++ requires use of templates to be C++- 
like. I typically think of using templates where the algorithm is the  
same but the types that have to be passed through the algorithm may  
differ in different implementations. I'm still having a difficult  
time wrapping my mind around the concept of using templates where the  
underlying algorithm will be very different.

>>> 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.
>>
>> I would  vote for 4a2 or 4a3 (in that order), but 4a1 would be ok if
>> the majority likes that most, of course.  Basically its a matter of
>> taste I think.  I am happy that the general point seems accaptable to
>> all so far: having sync, async, and task versions of the calls, w/o
>> explicit task factory.
>
> I kind of agree, but would prefer 4a3 because of the benfits it  
> provides.
>
> Regards Hartmut
>
>
>