[saga-rg] Task model...
Thilo Kielmann
kielmann at cs.vu.nl
Thu Nov 3 11:09:40 CST 2005
Hi Andre and all,
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.
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/
More information about the saga-rg
mailing list