version 1.0?

[psteinb]

I saw the HPX presentations from MeetingC++ 2014 and 2015 by @hkaiser and @sithhell respectively. I was quite impressed but am wondering about something simple: what is the roadmap to version 1.0?

I am asking as I personally refrain from suggesting software to peers or colleaques if it is below version 1.0. Sorry to be so naive, but given the fact that HPX receives new features (that are often ahead of C++ standardization) every time I see a presentation about it, I simply ask myself, when it is stable (note: not ready) to use?

I think HPX is a wonderful library/system, keep going folks!

[hkaiser]

@psteinb This is a very good question and not one which can be easily answered, but let me try.

Generally we think HPX is reasonably stable and usable for production already. It's development went through 11 or 12 major releases over almost 8 years. We use HPX for a number of larger projects ourselves and know of other people doing the same. So we're very conscious about API stability (see for instance here for how we track those). Any breaking changes to the API we try to do in stages over 2-3 releases (first deprecating it, hiding it behind pp constants, and only then removing the old version) to simplify the lives of our users.

You might ask: "Why haven't you released a V1.0 yet in this case"?

Code-quality-wise and feature-wise we could have done that at least a year ago. However, HPX is a large beast. We want to apply it to use-cases which have not been implemented too widely by other systems. We believe we have not fully implemented those, which makes us a bit hesitant to go for the 'big-bang'. Here is a list of such features (most of which are mentioned in some other ticket already):

• Implement fully transparent migration of objects in between distributed nodes (see Add hpx::migrate facility #559, Implement 'migration' to and from disk #1163)
• Finish the implementation of all algorithms as described in the 'Parallelization TS' (see Implement N4409 on top of HPX #1141, Extend parallel algorithms to work with hpx::partitioned_vector et.al. #1338, Adapt all parallel algorithms to Ranges TS #1668)
• Implement general-purpose distributed data structures (such as hpx::partitioned_vector, or hpx::unordered_map) and make those usable in a wide range of use-cases.
• Improve the efficiency of the communication layer in HPX, partly by just improving things in existing parcel-ports, partly by implementing new parcel-ports for other high-performance networking hardware (like Gemini or pure IB-verbs, see Parcelport Cleanup #1021, Need an efficient infiniband parcelport #1401)
• Provide better documentation

Now as I wrote this I realize that none of the things listed are expected to break APIs (they will mostly add things). There is, however one change which will break API compatibility. This change is related to how we expose remote objects (components) and how we want to reference those (see #1421). Currently all of this is based on the (low-level) hpx::id_type, but we would like to have something higher-level, more type-safe (see #864 for some discussion). This will most likely be a breaking change for applications which take advantage of HPX's ability to write distributed applications only, though. So far, we've had many discussions about this but have not settled on a final API yet.

Another reason for our hesitance to release a V1.0 is caused by the fact that we try to follow the standard and the standardization process as closely and as timely as possible. As you know, the standard itself (related to parallelization) is currently heavily under flux and no final uniform parallelization model has been found by the committee (something we are actively involved with, btw). So we can't guarantee the APIs we expose will not have to change because of changes in the C++ standard itself.

Now for the timeline. We plan to release V1.0 by August 2016 (one of our projects is running out at this point and HPX is planned to be one of the deliverables). It might very well be that some of the things listed above will not be 100% ready by that time, however. But we intend to settle on all major API issues for sure.

So by and large, we could have (and perhaps should have) released V1.0 a while ago. However, the lack of such a release is (in my book) not related to insufficient code quality or gaping holes in the functionality.

[psteinb]

wow, thanks a bunch for the reply. that gives me a much better understanding
on the way forward. I'll revisit my v1.0 paranoia for HPX then.

[hkaiser]

@psteinb quick update: we have implemented one of the main missing functionalities for V1.0 now: transparent migration is about to be merged to the master branch (see #1966).

[psteinb]

cool, that sounds good to me! thanks for keeping me updated.

On 01/31/2016 05:59 PM, Hartmut Kaiser wrote:

@psteinb quick update: we have implemented one of the main missing functionalities for V1.0 now: transparent migration is about to be merged to the master branch (see #1966).

---

Reply to this email directly or view it on GitHub:
#1896 (comment)