hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 252 seconds]
K-ballo1 is now known as K-ballo
Yorlik_ has joined #ste||ar
Yorlik has quit [Ping timeout: 252 seconds]
hkaiser_ has quit [Quit: Bye!]
K-ballo has quit [Read error: Connection reset by peer]
K-ballo has joined #ste||ar
aryan_j[m] has quit [Quit: You have been kicked for being idle]
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 240 seconds]
K-ballo1 is now known as K-ballo
hkaiser has joined #ste||ar
hkaiser has quit [Quit: Bye!]
hkaiser has joined #ste||ar
diehlpk_work has joined #ste||ar
bhumit[m] has quit [Quit: You have been kicked for being idle]
<satacker[m]>
hkaiser: Do I need to change anything in `libs/core/execution/include/hpx/execution/algorithms/detail/partial_algorithm.hpp` so that it works with ADL isolation ?
<Yorlik>
So - it seems HPX serialization cannot be used naively or "lean"
hkaiser has quit [Quit: Bye!]
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 248 seconds]
K-ballo1 is now known as K-ballo
hkaiser has joined #ste||ar
<Yorlik>
hkaiser: YT?
<hkaiser>
Yorlik: here now - sorry couldn't answer
<Yorlik>
NP.
<Yorlik>
I still need the hpx and hwloc dlls to make it work. That's kinda overkill.
<Yorlik>
I played with Boost, but I need streams and would prefer using a vector<byte/char> as buffer instead.
<Yorlik>
So - hpx serialization is not trivially usable like a header only library if I understood correctly.
<hkaiser>
Yorlik: come on, you have hpx built anyways ;-)
<Yorlik>
Sure ... but ... it still kinda stinks doing it that way.
<hkaiser>
you could build it with -DHPX_WITH_DISTRIBUTED_RUNTIME=OFF, that would leav you with hpx_core only
<hkaiser>
or try staticly linkong
<Yorlik>
I'll try. But I also want to use vcpkg .... :D
<hkaiser>
in theory it should be possible to make work, however it might need some build system tweaking
<Yorlik>
I should be a feature - just chose hpx[serialization] in vcpkg - or any other hpx goodie you can isolate.
<Yorlik>
BTW - is there a reason why MPI has to be a default feature ?
<Yorlik>
It broke a build - I had to manually disable all default features and then get the compression libs in again.
<hkaiser>
Yorlik: no
<Yorlik>
hkaiser: No what? The MPI thing?
<hkaiser>
mpi is not essential
<Yorlik>
hkaiser: MPI is a default feature in the 1.8.1 vcpkg port.
<Yorlik>
It adds bloat. If it's not essentiaql I'd suggest to remove it from the defaults.
<hkaiser>
well, you said you wanted to help with getting the vspkg support for V1.9.0, you can add it there ;-)
<Yorlik>
I could make a custom port and send it to you.
<hkaiser>
indeed, you could ;-)
<Yorlik>
Basically I'd just add some features to give you more control over the build with vcpkg.
<hkaiser>
do it such that it solves your problems
<Yorlik>
I'll look into it.
<hkaiser>
I still think that static linking might enable using serialization separately
<hkaiser>
not sure how that would integrate with vcpkg, though
<Yorlik>
There's still a lot to desire with vcpkg as nice as it is.
K-ballo has quit [Read error: Connection reset by peer]
K-ballo has joined #ste||ar
<Yorlik>
hkaiser: There is HPX_WITH_DISTRIBUTED_RUNTIME and also HPX_WITH_RUNTIME - are these mutually exclusive? What should be the defaults? I'd like to make both a feature (default or not).
<Yorlik>
So I guess the distributed runtime should be a default then
<hkaiser>
you don't need it ;-)
<Yorlik>
Maybe instead of tweaking the entire vcpkg build it's easier to provide a custom cmake config file as a feature - though we couldn't provide a path easily - it would have to live in some default location.
<hkaiser>
ok
<hkaiser>
that's doable, I think
<Yorlik>
Maybe an environment variable.
<Yorlik>
In normal vcpkg usage I think you cannot inject a CMAKE Variable, but you can query the environment.
<Yorlik>
E.g. $ENV{HPX_USER_CONFIG_FILE}. That could probably also be set when using CMakePresets.json.
<Yorlik>
And then load it in the portfile just before vcpkg_cmake_configure( ...
<hkaiser>
or chang eour CMakeLists.txt to include some other file, if requested
<Yorlik>
if the env var is empty it's just skipped
<Yorlik>
or if the file doesn't exist
<Yorlik>
hkaiser: Even when HPX_WITH_DISTRIBUTED_RUNTIME is OFF, the executable in the end still depends on hpx core dll and hwloc. Seems it's baked in pretty deep.
<hkaiser>
yes, that's what I said
<hkaiser>
it doesn't depend on hpx.dll anymore, though
<Yorlik>
hkaiser: It seems there is a way to tell the portfile things through an environment variable. This variable can also be set in a CMakepreset.json, but it is necessary to provide a list with environment variables to keep. So we can indeed communicate with more than just features, but it's a little cumbersome. The good news is - you can do that with virtually any vcpkg port.
<Yorlik>
That means for the HPX port, it should just provide a way to load an override file before the configure process starts and that file can be somewhere in userspace and is communicated with an environment variable.
<Yorlik>
vcpkg_cmake_configure should have all cmake variables the build system would ever need and the defaults should be provided in the portfile with a load of a custom optional override file before the configure step. So anyone could just use the defaults (like now) or change any variable that is opened for change from the outside by providing a file and two environment variables.