I vote +1 to split the repository into local only and distributed versions of HPX
My main reasons are that the full HPX is a very large project and this makes it difficult for new users to know which parts of the code are needed and which are not. Making small changes to anything in HPX requires a huge amount of knowledge of how the code interacts. When I first experimented with HPX, for example, I was confused by hello world client and server classes that were totally unnecessary for the simple tasks that I wanted to try out, but lack of knowledge, documentation and familiarity with the project caused me to waste time on simple tasks. This example is no longer valid since we have better hello world examples, but when I am looking for code to use in a project, one of the primary decision making criteria I use is how easy it is to understand or integrate the code into a project. A project containing smaller subprojects that build upon each other and add features is preferable to a monolithic project that tries to do all. Development on smaller projects is easier because it encourages encapsulation and abstractions that expose those features that are required by other projects without those other projects making intrusive changes to lower levels of the software stack. The distributed parts of HPX are extremely poorly documented, and the way serialization and parcelports interact for handling of messaging between nodes are not part of any standard. The desire to have a standards conforming task based execution framework makes the inclusion of the distributed HPX an anomaly (the parcelport interface needs significant redesign which could be best done in a separate repository anyway). A new user wishing to add distributed c++ features to HPX using their own RPC framework would be hindered rather than helped by the distributed features present in HPX currently. I would like to see HPX broken further into a core library containing task related synchronization, threading, scheduling and layers above moved into an/other library(ies). JB ________________________________ From: [email protected] <[email protected]> on behalf of Simberg Mikael <[email protected]> Sent: 07 June 2021 21:53:06 To: [email protected]; [email protected] Subject: {Spam?} [hpx-users] [VOTE] Proposal to split HPX into at least two smaller projects and repositories Dear HPX users and developers, The HPX users and developers at CSCS (that includes myself) have expressed an interest in separating the local-only and distributed functionality of HPX into two separate projects and repositories. This is a contentious topic, so before we do a large change like this we want to consult the community through a vote. My personal vote and motivation for the change will follow in a separate message. Practically speaking, the proposal is to move the on-node functionality of HPX (this includes futures, algorithms, basic CUDA/HIP support, a local-only runtime, and all the utilities required to support this) into a separate repository. The remaining distributed functionality of HPX would keep the hpx name, stay in the current repository, and it would gain one new dependency, called (e.g.) hpx-local. Releases of hpx and hpx-local would often be done together, but could be done independently of each other. The aim is to affect current users of distributed features of HPX as little as possible, while giving users of local-only features a project that, by default, gives them only local functionality. If there's consensus to go ahead with a split, we will also consider splitting HPX into more than two projects. Voting works as follows (from https://hpx.stellar-group.org/governance/): If a formal vote on a proposal is called (signaled simply by sending a email with [VOTE] in the subject line), all participants on the HPX user’s mailing list may express an opinion and vote. They do this by sending an email in reply to the original [VOTE] email, with the following vote and information: - +1: ‘yes’, ‘agree’: also willing to help bring about the proposed action - +0: ‘yes’, ‘agree’: not willing or able to help bring about the proposed action - -0: ‘no’, ‘disagree’: but will not oppose the action’s going forward - -1: ‘no’, ‘disagree’: opposes the action’s going forward and must propose an alternative action to address the issue (or a justification for not addressing the issue) This is a "Concensus approval" vote (see governance document for details). Responses from developers and users alike are encouraged. Please vote as soon as possible, but we will leave the voting open until Thursday 17th June. Kind regards, Mikael Simberg
_______________________________________________ hpx-users mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
