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