Send hpx-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hpx-devel digest..."
Today's Topics:
1. Re: [VOTE] Proposal to split HPX into at least two smaller
projects and repositories (Patrick Diehl)
2. Re: {Spam?} [hpx-users] [VOTE] Proposal to split HPX into at
least two smaller projects and repositories (Biddiscombe, John A.)
----------------------------------------------------------------------
Message: 1
Date: Wed, 9 Jun 2021 13:53:04 -0500
From: Patrick Diehl <[email protected]>
Subject: Re: [hpx-devel] [VOTE] Proposal to split HPX into at least
two smaller projects and repositories
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
My vote is -1. I backup Augustine for splitting HPX in local and
distributed libraries in one repo. We can adapt boost and one could only
build the parts of HPX needed. Like
cmake -DHPX__LOCAL=ON -DHPX_DISTRBUTED=OFF and so on
My major concern with having multiple repos is the Fedora package. The
concept there is one tar ball per package and no git clone or any
network access to get new sources during the build.
So I would have to maintain as many fedora packages as repos. I am happy
to maintain HPX on Fedora, but I would really prefer to have one repo,
build the repo and ship sub-packages. Like
hpx-local
hpx-local-devel
hpx-local-examples
hpx-distributed-openmpi
hpx-distributed-devel-openmpi
hpx-distributed-devel-openmpi
What I experienced is that having multiple packages with dependencies is
complicated and much more work.
Best,
Patrick
On 6/8/21 4:08 PM, Agust?n K-ballo Berg? wrote:
>
> My vote is -1. I am in favor of splitting HPX into local-only and
> distributed libraries, but I am strongly opposed to splitting the
> project across multiple repositories.
>
> With multiple repositories comes the need to synchronize them. The outer
> project would have to constantly be polling the core project for
> changes, bumping, testing, and then finally upgrading. Within a single
> repository this happens automatically, with multiple repositories this
> adds to boilerplate and noise in the form of constant bumps. The best
> tool git offers (to my knowledge) to keep track of the relation between
> repositories is submodules. They do allow to track the relation between
> repositories on a per-branch basis, which is imperative, but as mere
> hashes they tend to conflict all the time for merges and rebases. The
> split would necessitate a lot of work and effort to keep the two parts
> behaving as a cohesive thing, with the only exclusive advantage of
> reducing network traffic a bit when cloning.
>
> Splitting repositories could make more sense if the projects were
> eventually going to be developed in a less entangled way. For example,
> the distributed library could always track the last released version of
> the core library, never top-of-master. But that would not work for a
> research project, it would effectively turn distributed into a second
> class citizen.
>
> Alternative action: split libraries in a monorepo.
>
> Regards,
>
--
--
www.diehlpk.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
Url :
http://mail.cct.lsu.edu/pipermail/hpx-devel/attachments/20210609/24b3f02c/attachment-0001.bin
------------------------------
Message: 2
Date: Thu, 10 Jun 2021 08:32:07 +0000
From: "Biddiscombe, John A." <[email protected]>
Subject: Re: [hpx-devel] {Spam?} [hpx-users] [VOTE] Proposal to split
HPX into at least two smaller projects and repositories
To: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.cct.lsu.edu/pipermail/hpx-devel/attachments/20210610/1bf29ec4/attachment-0001.html
------------------------------
_______________________________________________
hpx-devel mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
End of hpx-devel Digest, Vol 72, Issue 4
****************************************
