[saga-rg] Task model...

[Hartmut Kaiser]

Thilo Kielmann wrote:

> taking the arguments into account that have been exchanged so
> far (and giving it another thought), I am voting for 4a2:
>
> reason:
>
> 4a1 indeed emulates a C of Fortran style syntax, which is NOT
> the right
>     thing to do (C++ should look like C++)
>
> 4a2 groups the three sets of operations in three sub objects
> (is that right?),
>     at least, there are 3 consistent places where the 3 respective
>     functionality groups belong (one place for sync, one
> place for async,...)
>
> 4a3 is using templates in the wrong way: a template defines
> some code skeleton
>     into which arbitrary instantiations can be put. (Like the
> notorious stack
>     from which you can make both a stack of int and a stack molecules)
>     But here, we anticipate exactly 3 possible
> instantiations, which goes
>     against the intuition of templates.

I strongly disagree here. The use case you've described is certainly the
most visible one for using templates (mainly for historical reasons and
because of the STL). But templates are additionally a very powerful tool to
enable generic and metaprogramming in C++ (hey templates are turing complete
in the end) and therefor allow for certain code generation and optimization
methods not available without them. Moreover, if you look at modern C++
languages (as they evolve in Boost or getting incorporated into the next C+
Standard) templates are getting used in a much wider context as only for
creating generic containers.

BTW: The templated syntax allows to separate the three implementations
evenly good as the implementation in 4a2 without exposing them to the
interface and without the additional (ok, perhaps marginal) overhead.

Regards Hartmut

>
>
> Thilo
>
> On Thu, Nov 03, 2005 at 10:56:14AM -0600, Andre Merzky wrote:
> > X-Original-To: kielmann at localhost
> > Delivered-To: kielmann at localhost.cs.vu.nl
> > Delivered-To: grdfm-saga-rg-outgoing at mailbouncer.mcs.anl.gov
> > X-Original-To: grdfm-saga-rg at mailbouncer.mcs.anl.gov
> > Delivered-To: grdfm-saga-rg at mailbouncer.mcs.anl.gov
> > Date: Thu, 3 Nov 2005 10:56:14 -0600
> > From: Andre Merzky <andre at merzky.net>
> > To: John Shalf <jshalf at lbl.gov>
> > Cc: Andre Merzky <andre at merzky.net>,
> > 	Simple API for Grid Applications WG <saga-rg at ggf.org>
> > Subject: Re: [saga-rg] Task model...
> > X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at
> > mailbouncer.mcs.anl.gov
> > X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at
> > mailbouncer.mcs.anl.gov
> >
> >
> > 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    |                             |
> > +-----------------------------------------------------------------+
> >
>
>
>
> --
> Thilo Kielmann
> http://www.cs.vu.nl/~kielmann/
>