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
hkaiser has joined #ste||ar
diehlpk has joined #ste||ar
diehlpk has quit [Ping timeout: 245 seconds]
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: Bye!]
zaara has joined #ste||ar
zaara has left #ste||ar [#ste||ar]
Yorlik has joined #ste||ar
<ms[m]>
pedro_barbosa: on linux you tend to be able to give include directories to the compiler with `-I` or `-isystem`, but if you're using CMake use `target_include_directories` or better yet `find_package(blah)` and `target_link_libraries(mytarget Blah::target)`
Yorlik has quit [Ping timeout: 268 seconds]
Yorlik has joined #ste||ar
FunMiles_ has joined #ste||ar
FunMiles has quit [Ping timeout: 260 seconds]
K-ballo has joined #ste||ar
<pedro_barbosa[m]>
<ms[m]> "pedro_barbosa: on linux you tend..." <- Yeah I'm using cmake going to give it a try, thanks for the suggestion
hkaiser has joined #ste||ar
<ms[m]>
hkaiser: yt? hpx was added to e4s (that ecp software stack... thing), which is nice!
<hkaiser>
was it now?
<hkaiser>
cool
<ms[m]>
one of the requirements for higher levels is that they have a small set of tests, which we don't have yet
<ms[m]>
yeah, apparently 1.6.0 was already there...
<hkaiser>
ms[m]: what is a 'small set of tests'?
<ms[m]>
mike heroux pushed it forward it seems like
<ms[m]>
well, that seems very open to interpretation...
<ms[m]>
I've put together two small smoke tests for futures and parallel algorithms
<ms[m]>
really nothing complicated
<hkaiser>
ms[m]: nice, might have been a result of me agreeing to serve on a advisory board for ECP led by Mike
<ms[m]>
do you think you could put together a small distributed one (or pick one from our testsuite) that I can add to it?
<ms[m]>
:D
<ms[m]>
yeah, possible
<hkaiser>
ms[m]: sure - what about distributed hello_world?
<ms[m]>
hmm, yeah, that might be enough actually
<hkaiser>
it's not a test, but if it runs (and finishes) all seems to be fine ;-)
<hkaiser>
ms[m]: btw, I'm looking for a name for a facility we need to add
<ms[m]>
yeah, looking at what the other projects use something simple is probably fine
<ms[m]>
if they're not happy with that we can always expand...
<ms[m]>
what are you adding?
<hkaiser>
f.wait() and wait_all do not check for exceptions (by design), so people use just those, which may cause for exceptions to be swallowed
<ms[m]>
btw, I'll ping you on the e4s test thingy pr once it's up, you can have a look there
<hkaiser>
I would like to have something like throw_if_exceptional() or something that simply checks all futures it was invoked with and rethrows exceptions if any (without invalidating the futures otherwise)
<hkaiser>
ms[m]: ok, thanks
<hkaiser>
to be used as: wait_all(futures, ...); throw_if_exceptional(futures, ...);
<ms[m]>
hmm
<hkaiser>
or even a combined one, not sure of that - however
<ms[m]>
yeah, I guess the choice is between future::wait(some_throw_tag) and future::wait_and_throw_if_exceptional() (with better names...)
<ms[m]>
are there other options?
<hkaiser>
I didn't want to touch the existing facilities
<ms[m]>
the tag would be easy to forward through wait_all to the underlying wait
<hkaiser>
wait_all doesn't call wait
<ms[m]>
but if wait() still stays unchanged, and wait(blah) is a separate overload?
<ms[m]>
mmh
<hkaiser>
ok, that might work
<ms[m]>
not sure if it's more confusing to have them be so similar
<hkaiser>
throw_if_exceptional is my first choice for a name, but combining it as wait_and_throw_if_exceptional() would work for a fused facility
<hkaiser>
it always bugged me that for single futures you have to use f.wait(), but for more than one there is a separate utility
<ms[m]>
at least I would expect wait in the name, even though one of course has to wait for the future to find out if it's exceptional
<hkaiser>
right, good point
<ms[m]>
wait_or_throw?
<hkaiser>
if throw_if_exceptional was called without calling wait_all first it would have to wait anyways
<ms[m]>
the if_xxx is pretty good to have there though...
<hkaiser>
ok, the combined facility it is
<ms[m]>
yeah
<ms[m]>
uh
<ms[m]>
don't pay too much attention to my opinion here
<hkaiser>
what about wait_any and friends
<ms[m]>
throw_if_exceptional is not bad either
<ms[m]>
what would the semantics even be there?
<hkaiser>
the sam
<hkaiser>
e
<hkaiser>
wait as before, but throw if the future that became ready is exceptional
<hkaiser>
essentially for auto& f: futures) if (f.is_ready() and f.is_exceptional()) f.get();
<ms[m]>
so only take the first ready one into account, not matter the status
<hkaiser>
yes
<ms[m]>
that pseudocode is not quite accurate, right?
<hkaiser>
it misses a '('
<ms[m]>
:P
<hkaiser>
for (auto& f: futures) if (f.is_ready() && f.is_exceptional()) f.get();
<ms[m]>
I mean this: for (auto& f : futures) if (f.is_ready()) { if (f.is_exceptional() f.get(); else return; }
<ms[m]>
I'm just checking that we are talking about the same behaviour...
<ms[m]>
and there are for sure braces and parentheses missing there
<hkaiser>
ms[m]: no, if none of the futures is exceptional it should not do anything
<hkaiser>
well, assuming it has done the waiting already
<ms[m]>
hkaiser: but if the waiting has already been done the `is_ready` is unnecessary
<ms[m]>
and if you have n non-exceptional futures, and one exceptional will it throw?
<ms[m]>
because you're waiting for any, not all
<ms[m]>
well...
<ms[m]>
not sure anymore
Yorlik has quit [Read error: Connection reset by peer]
<ms[m]>
you're talking about wait_any(futures); throw_if_exceptional(futures);?
<ms[m]>
or wait_any_throw_if_exceptional?
Yorlik has joined #ste||ar
<hkaiser>
ms[m]: yes, for wait_any you can stop the loop after the first ready future
diehlpk_work has joined #ste||ar
K-ballo has quit [Read error: Connection reset by peer]