[saga-rg] Task model...

[Andre Merzky]

Hi John, Thilo, Group, 

Hartmut and I would like to argue about the C++ bindings.
We would like to come to an agreement soon, as our
implementation is dealing with the async part right now.

As reminder:

---------------------------------------------------------------------
Example 4a: more versions in C++

4a1:               d.mkdir         ("test/");
                   d.mkdir_sync    ("test/"); // same
  saga::task t_1 = d.mkdir_async   ("test/");
  saga::task t_2 = d.mkdir_task    ("test/");

4a2:               d.mkdir         ("test/");
                   d.sync .mkdir   ("test/"); // same
  saga::task t_1 = d.async.mkdir   ("test/");
  saga::task t_2 = d.task .mkdir   ("test/");

4a3:               d.mkdir         ("test/");
                   d.mkdir <sync>  ("test/"); // same
  saga::task t_1 = d.mkdir <async> ("test/");
  saga::task t_2 = d.mkdir <task>  ("test/");
  ---------------------------------------------------------------------


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.


> 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?


> 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.


> 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 :-)


> 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.

Hehe - I thought the same :-)  Hartmut likes that version very
much.  To me it appealed after pondering over it for a couple of
days.  Now I think it is cute, and quite expressive.


> It would certainly be easier to  
> create multi-language bindings for a single code base if we stick  
> with something more conventional like 4a1.

I think that C and Fortran bindings for this part are straight
forward anyway, there is no need to reflect that in C++...


> 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.


> 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.

> The only implementation I'm outright  
> against is the 4b example.

Good! :-)

Thanks, Andre.


> -john



-- 
+-----------------------------------------------------------------+
| Andre Merzky                      | phon: +31 - 20 - 598 - 7759 |
| Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 |
| Dept. of Computer Science         | mail: merzky at cs.vu.nl       |
| De Boelelaan 1083a                | www:  http://www.merzky.net |
| 1081 HV Amsterdam, Netherlands    |                             |
+-----------------------------------------------------------------+