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>
john98zakaria[m]: hmmm, interesting use case
<hkaiser>
you're stretching the boundaries ;-)
<john98zakaria[m]>
I wanted to just replace an mpi call without having to modify my class instance, just to see if it works
<john98zakaria[m]>
So I went the lazy way of calling it in the loop for every rank :D
<hkaiser>
registering and finding by name might be slow - (could be a remote operation)
<john98zakaria[m]>
Have a workling algorithm now, optimise later
hkaiser has quit [Quit: Bye!]
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 276 seconds]
K-ballo1 is now known as K-ballo
Yorlik has joined #ste||ar
Undername has joined #ste||ar
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 260 seconds]
K-ballo1 is now known as K-ballo
Undername has quit [Quit: Leaving.]
hkaiser has joined #ste||ar
Undername has joined #ste||ar
K-ballo has quit [Ping timeout: 246 seconds]
hkaiser has quit [Quit: Bye!]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
<Undername>
Hello, in the documentation for HPX, in "Getting HPX" it says to check out the latest stable tag "git checkout 1.7.1". Is this still accurate or is the latest stable 1.8.0 or 1.8.0-rc2 ?
<hkaiser>
Undername: good catch, it's 1.8 now
<hkaiser>
Undername: could you give me the link with that information, I'll fix the docs
<Yorlik>
We have a header only library, which needs a user supplied enum. This leads to a header inclusion ordering constraint, which we don't really like. Is there a way or pattern to circumvent this or should we just live with it?
<hkaiser>
Undername: thanks again, pls see #5923 for a fix
<hkaiser>
Yorlik: #include sequencing issues are always nasty
<hkaiser>
I'd add an #error if your user constraint is not met
<Yorlik>
Yup. And I have no good idea how to fix it.
<Yorlik>
asserts for the win?
<Yorlik>
static ones ofc.
<hkaiser>
Yorlik: #error "please #include file <...> before this one"
<Yorlik>
Will do. I'm on it.
<Undername>
Is it possible in HPX to have multiple versions for a function/task (CPU, CUDA, OpenCL, etc), which would then be executed in a smart way by the scheduler for example on the GPU if CUDA is faster or on CPU if GPU is full and CPU idle? (similarly to how StarPU works (https://starpu.gitlabpages.inria.fr/))
<Yorlik>
hkaiser: Thanks for the tip - it also clared up some mysterious other errors that wouzld otherwise have been hard to track (came up after refactoring)
Undername has quit [Quit: Leaving.]
hkaiser has quit [Quit: Bye!]
diehlpk_work has joined #ste||ar
hkaiser has joined #ste||ar
<gonidelis[m]>
is there any particular reason to `return {v}` in a given function? Since it's a single element list
<hkaiser>
gonidelis[m]: might not be a list at all
<hkaiser>
some_type foo() { returning {x}; } will return some_type{x}
<gonidelis[m]>
?
<gonidelis[m]>
oh
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 248 seconds]
K-ballo1 is now known as K-ballo
<akcube[m]>
While going through some of the code in `hpx/parallel/algorithms` I noticed that the code treated both algorithms called without the execution policy overload and with the `seq` execution policy the same and called the sequential code written in the `algorithms/detail`. But according to the standard (https://en.cppreference.com/w/cpp/algorithm/execution\_policy\_tag\_t)
<akcube[m]>
> During the execution of a parallel algorithm with any of these execution policies, if the invocation of an element access function exits via an uncaught exception, `std::terminate` is called, but the implementations may define additional execution policies that handle exceptions differently.
<akcube[m]>
This includes `seq`. While I don't get the rationale behind why the standard would mandate it for `seq` was there some reason HPX implements it differently?
<hkaiser>
akcube[m]: historical reasons
<hkaiser>
earlier versions of the algorithm proposal defined the exception handling differently, that's what we have implemented
<akcube[m]>
Ah right. Should we move to the new standard definition?
<hkaiser>
all of our execution policies do handle exceptions (except for unseq/par_unseq, and simd/par_simd, which call terminate)
<hkaiser>
akcube[m]: frankly I think that at least attempting to handle exceptions is preferrable to simply calling terminate
<hkaiser>
the standard went back to calling terminate as they ran out of time to properly specify exception handling for algorithms
<akcube[m]>
Yeah. I can understand calling terminate for parallel versions. Non-parallel code should be able to handle exceptions.
<hkaiser>
you can handle exceptions properly even for parallel (non-vectorized) code - that's what we do
<akcube[m]>
How do we handle returning the exceptions? IIUC the standard did not want to create a new immutable container to return the exception list right?
<hkaiser>
for vectorized code there is indeed no way of handling exceptions
<hkaiser>
we have hpx::exception_list, which is collecting the exceptions and is rethrown
<hkaiser>
not though, std::bad_alloc is handled separately and is always rethrown directly
<hkaiser>
note though*
<akcube[m]>
Right. Yeah makes sense, though I feel this does complicate the design a decent bit.
<hkaiser>
akcube[m]: yah, sure - we have not measured perf overheads for this, however
<akcube[m]>
Yep got it. Just didn't realise we had the exception_list stuff implemented. Really cool.