search

charmplusplus / charm

The Charm++ parallel programming system. Visit https://charmplusplus.org/ for more information.
Apache License 2.0
201 stars 49 forks source link

Entry Methods Always Take lvalue References (feature/bug) #1500

Open nilsdeppe opened 7 years ago

nilsdeppe commented 7 years ago

Original issue: https://charm.cs.illinois.edu/redmine/issues/1500

I'm filing this bug/feature request is mainly to start a discussion of C++11 and template metaprogramming being used to simplify or even eliminate Charm interface files.

Currently if I declare a function argument as pass-by-value in an Interface file the generated function in the .def.h file still takes a const lvalue reference to the object. I realize there are likely deep reasons for this implementation. However, it would be very nice to have an interface that is more C++ compliant. Currently it seems like one must have a callback to delete any data that was sent, which seems like wasted communication. (Is there a better approach that I don't know of? Messages seems like an option) If entry methods were function templates in general then maybe forwarding references could be used together with SFINAE to do some automation of "doing the right thing". That is, if the deduced type is an lvalue reference the current implementation is used, but if it is an rvalue reference then the data should be stored locally somehow since this is generally what the programmer would be expecting.

Unfortunately I think resolving this issue would require C++11 and potentially a fairly major redesign of the way Charm entry methods work. However, not knowing how the latter works in detail I cannot comment on it. I saw some bugs about use "pure C++" for entry methods but because there wasn't a detailed description I'm not sure if they are getting at the same issue. I think this would be an interesting problem to approach with template metaprogramming in C++11.

PhilMiller commented 5 years ago

Original date: 2017-04-12 19:57:06

This is indeed the direction we're aiming to go, and want to move on in the not-too-distant future. There's room for big reductions in how much the user has to write, and also performance improvements (e.g. bug #921). We'll look forward to discussing this with you (e.g. at the workshop), and try to get more of our plans and ideas out in the open so that users can see it.

nilsdeppe commented 5 years ago

Original date: 2017-04-13 01:10:09

Okay, that's really good news. We would be happy to be involved in brainstorming, development and testing of any new infrastructure. We've made very extensive use of template metaprogramming in our code. Almost everything is decided at compile time that can be and with C++11 compilation time doesn't need to increase much, even with very TMP heavy code. We also have a very generic wrapper around Charm++ arrays that we are planning an making more generic in the near future (weeks timescale). This will hopefully be useful for drawing some inspiration and learning some lessons on where to go with TMP in Charm++.

stwhite91 commented 5 years ago

Original date: 2018-04-13 23:07:21

Should this be marked merged once we have perfect forwarding and r-value references supported? We already support r-value references in mainline now, and the perfect forwarding for inline and local entry methods is under development for 6.9.0

epmikida commented 5 years ago

Original date: 2019-04-03 20:38:22

Perfect forwarding changes have all been merged. Should this be marked as closed then? I think we covered all the main points in the initial post.