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 | Everybody: please respond to the documentation survey: https://forms.gle/aCpNkhjSfW55isXGA
nanmiao has quit [Quit: Client closed]
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: Bye!]
oj has joined #ste||ar
hkaiser has joined #ste||ar
<jedi18[m]> hkaiser: gonidelis If you're free today, could we have the gsoc meeting today?
<hkaiser> jedi18[m]: I can't make it this morning, may have time in the afternoon, but that's probably too late for gonidelis or rori - please go ahead and meet without me
<jedi18[m]> @hkaiser We could shift it to tomorrow or in the next few days if you prefer, or if you're going to be busy in the next few days I'll meet with them today
<jedi18[m]> * hkaiser We could shift it to tomorrow or in the next few days if you prefer, or if you're going to be busy in the next few days I'll meet with them today
<hkaiser> Monday after 10am CDT should work
<jedi18[m]> Oh ok great that works for me, gonidelis rori is that okay?
K-ballo has joined #ste||ar
<gonidelis[m]> jedi18: hkaiser yes.
<gnikunj[m]> hkaiser: is HPX's testing module the same as Boost.Test?
<hkaiser> no
<hkaiser> HPX testing is just a very lightweight set of macros
<gnikunj[m]> what's it based on then?
<hkaiser> shrug
<gnikunj[m]> <hkaiser "HPX testing is just a very light"> seemed like it
<hkaiser> it's a lot less than boost test, there are elements similar, sure - but what else should a testing framework do
<gnikunj[m]> lol, that's true
<srinivasyadav227> what is the difference btw `hpx::util::invoke` and `HPX_INVOKE`?
<hkaiser> srinivasyadav227: the first is a function, the second is a macro to be used internally
<hkaiser> functionally they are equivalent
<hkaiser> the macro saves one function call level, and btw, util::invoke is implemented in terms of HPX_INVOKE: https://github.com/STEllAR-GROUP/hpx/blob/master/libs/core/functional/include/hpx/functional/invoke.hpp#L37-L42
<hkaiser> the rationale is that the macro simplifies the compiler's job of inlining, so it improves code generation quality
<srinivasyadav227> hkaiser: oh, cool got it ;-)
<hkaiser> srinivasyadav227: for a simple function HPX_INVOKE(f, args...) is essentially equivalent to f(args...)
<srinivasyadav227> hkaiser: yeah!, its clear now! ;-)
<srinivasyadav227> hkaiser: i have other question please, is there a way to have a different overload on `parallel` or `sequential` method in `algorithm struct` bases on the ExPolicy type? as some of the algorithm needs separate impl from the existing ones for adding `simd` or `simdpar` overloads?
<hkaiser> srinivasyadav227: wouldn't it better to overload the algorithm (tag_dispatch) itself?
<hkaiser> just to keep things separate?
<hkaiser> srinivasyadav227: mind, I'm not sure - just asking
<srinivasyadav227> hkaiser: if a not wrong, is it like this https://github.com/STEllAR-GROUP/hpx/blob/master/libs/parallelism/algorithms/include/hpx/parallel/algorithms/all_any_none.hpp#L658-L669? if i need to have a seperate impl for all_of with `simdpar` policy then i do a tag_dispatch ?
<hkaiser> right
<hkaiser> srinivasyadav227: but the all_of/any_of/none_of already use loop_n, wouldn't that be sufficient for your needs?
<srinivasyadav227> hkaiser: cool, i thinks thats a perfect solution, to keep datapar things separate ;-)
<srinivasyadav227> hkaiser: i was trying to get the `all_any_none` datapar with the existing code (util::loop_n) but here https://github.com/STEllAR-GROUP/hpx/blob/master/libs/parallelism/algorithms/include/hpx/parallel/algorithms/all_any_none.hpp#L495 `if` condition becomes a problem , it needs masking and need some other trait(find_first)
<hkaiser> ahh
<srinivasyadav227> so with that if condition it returns a mask on simd/simdpar, but we need a bool from that mask
<hkaiser> I'd suggest to go with the solution that enables minimal code duplication
<hkaiser> overloading the algorithm itself is certainly an option, but the amount of duplication is not optimal
<hkaiser> srinivasyadav227: creating another customization point for these alogirhtms along the lines of loop_n might be better
<hkaiser> srinivasyadav227: sequential_find_if seems to be a good candidate here
<hkaiser> that loop_n you linked could be rewritten using sequential_find_if as well
<hkaiser> hmm, we probably used loop_n to be able to cancel chunks once the result was found
<srinivasyadav227> <hkaiser "hmm, we probably used loop_n to "> cancel tok was not implemented for datapar
<srinivasyadav227> <hkaiser "overloading the algorithm itself"> true ;-)
<srinivasyadav227> <hkaiser "that loop_n you linked could be "> hkaiser: i am trying to understand, but its still not clear, can you please elaborate it ?
<hkaiser> normally, we use the same sequential algorithms for the sequential implementation and the parallel implementation (for each chunk)
<hkaiser> for all_of and friends we could have used sequential_find_if for both as well, but we decided to use loop_n to be able to cancel all chunks if we found a negative result somewhere
<hkaiser> srinivasyadav227: does that make sense?
<srinivasyadav227> oh alright, i get it now
<srinivasyadav227> yes! ;-)
<hkaiser> srinivasyadav227: if you turn sequential_find_if into a customization point, you could overload it for sequential, parallel, and for simd
<hkaiser> based on the execution policy
<srinivasyadav227> hkaiser: ok, so that will change the existing code from loop_n to sequential_find_if ?
<hkaiser> to the specialized sequential_find_if CPO, yes
<srinivasyadav227> hkaiser: okay, got it now
<hkaiser> perfect, thanks
<srinivasyadav227> hkaiser: well, i should say thanks a lot! xD
diehlpk_work_ has joined #ste||ar
diehlpk_work has quit [Ping timeout: 250 seconds]
oj has quit [Remote host closed the connection]
diehlpk has joined #ste||ar
diehlpk has quit [Client Quit]