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-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: Bye!]
Yorlik has joined #ste||ar
<ms[m]> psa: piz daint is down for maintenance today, jenkins runs there are suspended for the moment
pansysk75[m] has quit [Quit: You have been kicked for being idle]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
aalekhn has joined #ste||ar
<Yorlik> hkaiser: YT?
<Yorlik> Is HPX serialization part of the official public API? We'd like to use it in our networking code. Since we also have a client side I'd also like to know how to just use HPX serialization without any other HPX functionality.
<hkaiser> Yorlik: in a meeting
<Yorlik> KK
diehlpk_work has joined #ste||ar
<hkaiser> Yorlik: here now
<john98zakaria[m]> <Yorlik> "Is HPX serialization part of the..." <- Here... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/3b503567994a091a2799a3765a882bba8f4580ca)
<hkaiser> serialization is part of the API as it is essential for our remote operation
<hkaiser> thanks john98zakaria[m]
<hkaiser> Yorlik: a good starting point is Boost's serialization docs, sans the namespace change boost::serialization --> hpx::serialization
<hkaiser> and yes, you can use serialization without anything else (at least in principle), we might have to jump through some build-sytem hoops, however
<john98zakaria[m]> I don't really understand how defining serialize, defines unserialize
<john98zakaria[m]> Just magic even on the boost side archive thing
hcq9102 has joined #ste||ar
<K-ballo> you don't define serialize nor unserialize (deserialize), you define member visitation
<K-ballo> then member-wise serialization/unserialization is applied to member visitation
<Yorlik> john98zakaria[m], hkaiser: Thanks !
hcq9102 has quit [Quit: Client closed]
hkaiser has quit [Quit: Bye!]
<gonidelis[m]> hkaiser: K-ballo how does an impl. assure some progress guarantee
<gonidelis[m]> how can you be sure that the code you wrote, does actually provide the concurrent forward progress guarantee for example?
<K-ballo> for example, if your code never blocks
<K-ballo> if your code never blocks then what other threads do doesn't matter, you'll always make progress
hkaiser has joined #ste||ar
<gonidelis[m]> If a thread offers parallel forward progress guarantee, the implementation is not required to ensure that the thread will eventually make progress if it has not yet executed any execution step (I/O, volatile, atomic, or synchronization)
<Yorlik> hkaiser: YT?
<gonidelis[m]> making progress means performing one of those steps as mentioned on the predefinitions above this text
<Yorlik> How would I have to compile HPX to have a minimal serialization functionality and nothing else?
<gonidelis[m]> K-ballo: so it bnasically says: "if the thread does not do on of those 4 then the thread does not do one of those four" ?
<K-ballo> it says that a thread of execution that hasn't yet started may never start
<K-ballo> if it does eventually start, then it will eventual make progress
<K-ballo> thing bounded thread pool, do you know what that is?
<hkaiser> Yorlik: you don't need to compile HPX at all as serialization is header only
<Yorlik> Great ! Thanks!
<hkaiser> Yorlik: please note that you're on your own with that, we have never done this before
<hkaiser> but if you run into issues, pls let us know
<Yorlik> It's a real use case.
<hkaiser> indeed
<Yorlik> We have a non HPX client which needs to communicate woith a HPX server
<gonidelis[m]> a thread pool with const number of threads?
<Yorlik> So we just need the "language module"
<K-ballo> not constant, just bounded
<hkaiser> serialization only depends on a handful of other HPX modules: https://hpx-docs.stellar-group.org/branches/master/report/master/core/serialization.html
<gonidelis[m]> not infinite that is?
<K-ballo> yes
<K-ballo> a thread pool with a constant number of threads is nevertheless also forward progress
<gonidelis[m]> how the hell can there be an infinite number of threads?
<gonidelis[m]> computers are finite machines
<gonidelis[m]> ;p
<K-ballo> bah, don't waste my time
<gonidelis[m]> it's a serious question
<gonidelis[m]> how can ther be inifnite number of threads
<hkaiser> gonidelis[m]: read 'as many threads as needed'
<K-ballo> it's an upper bound on the number of threads
<K-ballo> if the bound is 4 then the thread pool can at any time have 0, 1, 2, or 3 threads
<gonidelis[m]> ah
<gonidelis[m]> nice
<gonidelis[m]> yes
<K-ballo> whereas the const one as you said would always have 4, from start to end
<K-ballo> regardless, both only guarantee forward progress
<gonidelis[m]> ah
<gonidelis[m]> yes
diehlpk_work has quit [Ping timeout: 272 seconds]
<gonidelis[m]> concurrent is more strict than forward, no?
<K-ballo> uh
<K-ballo> strict?
diehlpk_work has joined #ste||ar
<K-ballo> I meant .. what did I mean? parallel forward progress
<K-ballo> concurrent forward progress guarantees what parallel forward progress guarantees and then more
<K-ballo> concurrent can execute things that parallel can't, so that would make it less "strict"?
<gonidelis[m]> yep. i confused "guarantees" with "Demands"
<K-ballo> an unbounded thread pool gives concurrent guarantees
<K-ballo> whenever there's a new piece of work you can always spawn a new thread to run it (concurrently with whatever else is running already)
<K-ballo> it never has to wait (block) for spawned threads to free up
diehlpk_work_ has joined #ste||ar
diehlpk_work has quit [Ping timeout: 272 seconds]
diehlpk_work has joined #ste||ar
diehlpk_work_ has quit [Ping timeout: 272 seconds]
<gonidelis[m]> `auto&& [v4] = this_thread::sync_wait(std::move(then4)).value();`
<gonidelis[m]> what does this syntax mean: `[v4]`?
<hkaiser> structured bindings
<gonidelis[m]> why are they useful?
<K-ballo> they are convenient
<K-ballo> it's sugar for `auto&& res = ...;` followed by `res.whatever_the_name_of_the_first_element_is`
<gonidelis[m]> just the first elemen ?
<gonidelis[m]> what about the other members?
<K-ballo> there's only one binding in [v4]
<K-ballo> and there won't be more members on the returned thing, or the binding would yield a compilation error
aalekhn has quit [Quit: Connection closed for inactivity]
<K-ballo> look up some more examples at cppref
<gonidelis[m]> yes!
<gonidelis[m]> thanks
<gonidelis[m]> a member can be a whole vector (?)
<gonidelis[m]> it does not have to be each element of the vector necessarily
<gonidelis[m]> ?
<K-ballo> elements of a vector aren't members
<gonidelis[m]> .a member can bind to a whole vector. it does not have to bind to each element of the vector neceessarily ? ^^
<gonidelis[m]> and one other thing. why aren't the return values of the algorithms adaptor/factories inp 2300 sth like `execution::sender<auto> _factory_()` and they are rather `execution::sender auto`?
<gonidelis[m]> seems like `sender` is a concept?
<K-ballo> sender is indeed a concept
<gonidelis[m]> final one:
<gonidelis[m]> However, where the sender returned from then sends exactly what that function ends up returning - let_value requires that the function return a sender, and the sender returned by let_value sends the values sent by the sender returned from the callback. This is similar to the notion of "future unwrapping" in future/promise-based frameworks.
<gonidelis[m]> i fail to understand the difference
<K-ballo> which difference?
<gonidelis[m]> `let_value` returns what `callback` returns and `then` returns what the `function` (aka callback) returns
<gonidelis[m]> between `let_value` and `then`
<gonidelis[m]> oh in `then` the callback does not have to return a sender?!
<gonidelis[m]> no! it's an adaptor. it has to
<gonidelis[m]> yeah I don't get it
<gonidelis[m]> it's more like `let_value` is required for its sender to send the same value that the callback sender returns while `then` does not have this constrain (although I cannot figure out what some other case might be)
<K-ballo> "future unwrapping" turns future<future<X>> into future<X>
<gonidelis[m]> so let_value is being used for the corresponding of future unwrapping?
<hkaiser> gonidelis[m]: frankly, I don't see a relation between let_value and future unwrapping, but I might miss something
<gonidelis[m]> gah
<gonidelis[m]> i will talk to eric
hkaiser has quit [Quit: Bye!]
diehlpk_work has quit [Ping timeout: 250 seconds]
diehlpk_work has joined #ste||ar
diehlpk_work has quit [Remote host closed the connection]