K-ballo changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
nanmiao has quit [Quit: Connection closed]
nanmiao has joined #ste||ar
<diehlpk_work>
ms[m], heller1 gnikunj[m] gonidelis[m] We got accepted for GSoC
<srinivasyadav227>
diehlpk_work: woooo!! thats a great news!!
hkaiser has joined #ste||ar
nanmiao has quit [Quit: Connection closed]
K-ballo has quit [Quit: K-ballo]
bita_ has quit [Ping timeout: 264 seconds]
bita_ has joined #ste||ar
bita_ has quit [Ping timeout: 264 seconds]
hkaiser has quit [Quit: bye]
diehlpk_work has quit [Remote host closed the connection]
V|r has joined #ste||ar
Vir has quit [*.net *.split]
<jedi18[m]1>
gonidelis: What's the tagged_pair? I can replace that with hpx::parallel::util::in_out_result too right?
<gonidelis[m]>
jedi18: hey
<gonidelis[m]>
yeah exactly
<gonidelis[m]>
be sure that you remove the tagged_pair include and add the result_types.hpp one ;)
<gonidelis[m]>
diehlpk_work: \o/ !!!!
<gonidelis[m]>
jedi18: thanks for the bug notice btw! awesome work ;)
<sestro[m]>
Hi, I have a question regarding the instrumentation of HPX using APEX. I'm having trouble getting `hpx::util::annotated_function` to work. From my understanding I should be able to wrap a lambda with this in order to get the annotation into APEX. Yet in the trace the time apparently is attributed to the generic dispatch routine `async_launch_policy_dispatch`. If i use an instance of `hpx::util::annotate_function` in my
<sestro[m]>
lambda, the annotation works but there is a serious performance overhead. What am I missing here?
<hkaiser>
sestro[m]: hmmm, annotated_function should work, would you have a small example for us?
<sestro[m]>
<hkaiser "sestro: hmmm, annotated_function"> Sure, let me try to extract a small test.
<hkaiser>
sestro[m]: I added a coment there, could you try that, please?
<hkaiser>
note: annotate vs. annotated
<srinivasyadav227>
hkaiser: build moved forward from 32% to 35% after making change in libs/CMakeLists.txt
<sestro[m]>
<hkaiser "sestro: I added a coment there, "> The version using `hpx::util::annotate_function` works as intended, I was wondering about the `hpx::util::annotated_function` wrapping the lambda.
<srinivasyadav227>
I used make VERBOSE=1 -j1, there would be no problem if I use -jn n > 1 right, with1 thread its slow, so I want to speedup
<srinivasyadav227>
anyway, i think with -j1 its easy to debug ;)
<zao>
We got GSoC again? Neato.
<zao>
srinivasyadav227: The build should be safe to build in parallel, but when it comes to errors it helps to fall back to -j1 to ensure that you get linear progression through the files to be able to know that it's building the file you're having trouble with when building again.
<srinivasyadav227>
zao: got it! ;)
<zao>
If you have n>1, you may be getting errors from a "later" file that happens to be faster to compile that time around.
<zao>
I've seen a streamer jump all over his codebase thinking he had fixed problems as other files snuck in with new errors in their IDE :)
<hkaiser>
sestro[m]: but you can use the annotate_function to the same effect
<hkaiser>
srinivasyadav227: so what's the problem now?
<srinivasyadav227>
hkaiser: actually make failed at another step, but my console has only half error shown, trying to figure out to get full error message into some file and copy to gist
<hkaiser>
ok
<sestro[m]>
hkaiser: okay, I'll do that
<zao>
srinivasyadav227: I'm a fan of appending "2>&1 | tee compile.log"
<zao>
Still get output to the terminal (but probably without colouring), and a hardcopy in the filename passed to tee.
<jedi18[m]1>
Glad to know ste||ar got selected for gsoc! :D I should probably try a few more PRs before I finalize on an idea and start working on a proposal right?
<hkaiser>
jedi18[m]1: you should start thinking about an idea asap, but PRs are always welcome ;-)
<jedi18[m]1>
Ok yeah, we have less time this year compared to previous years, and I'm definitely gonna try more PRs, plus it'd probably help me write a better proposal
<zao>
Do you have your eye on an existing project from the list on the wiki (which I assume we still have), or something novel?
<srinivasyadav227>
or should I force make again and show the output?
<jedi18[m]1>
hkaiser: Well I was thinking of implementing shift_left and shift_right parallel algorithms but since you said that's relatively easy compared to other algorithms, I thought I might also add some of the range based algorithms so that the proposal dosen't seem too small
<jedi18[m]1>
Unless implementing shift_left and shift_right are enough for a proposal?
<jedi18[m]1>
I have no idea about the difficulty of each project so please correct me if I'm wrong
<srinivasyadav227>
hkaiser:for GSoC I am thinking of Separate the datapar algorithms(#5175) and Add Vec support (#2271) as both are together
<srinivasyadav227>
currently I have my End Semester exams, thats the reason I could not make much progress (could not extract much time as I need to prepare my exams), they would finish on March 17, from then I can really focus on, (and no exams for at least 4-5 months more ;) )
<hkaiser>
ms[m]: is HPX_ASSERT available in device code?
<gnikunj[m]>
aah, no. KOKKOS_LAMBDA when used with reductions have two arguments. Only in those cases, the 2nd argument (taken by reference) the equivalent of our returned argument.
<gnikunj[m]>
ms: tests, seem to run just fine for both host and device.
<hkaiser>
gnikunj[m]: I think HPX_ASSERT in device code is a noop, but I'm not sure
<gnikunj[m]>
hkaiser: got it. Will convert that to hpx::get
<hkaiser>
ahh, thanks
<hkaiser>
wrt assert: makes sense
<gnikunj[m]>
we can't make it look any fancier, thanks to CUDA stream and their error codes :/
<hkaiser>
gnikunj[m]: that's fine
<gnikunj[m]>
hkaiser: made the changes required. Anything else?
<gnikunj[m]>
we're good to go for tasking and error handling with kokkos interface now
<gnikunj[m]>
all that remains is implementing those bulk_async_execute as we talked and then moving to adding things directly in Kokkos execution space
<hkaiser>
yes
nanmiao has quit [Quit: Connection closed]
<hkaiser>
see my email to Keita, feel free to add more future work points during the meeting
<gnikunj[m]>
should I add the point that we have exception handling in there as well?
<hkaiser>
yes, I forgot to mention that the semantics are equivalent to what we've had so far
nanmiao has joined #ste||ar
<hkaiser>
gnikunj[m]: may I nitpick some more?
<gnikunj[m]>
sure
<hkaiser>
the code you have now needs to invoke a default constructor and at least one assignment operation, I think you can get away with (at least) one initialization and in the erro case one default construction
K-ballo has quit [Quit: K-ballo]
<gnikunj[m]>
let me think about it.
K-ballo has joined #ste||ar
<gnikunj[m]>
the meeting is right now, right?
<hkaiser>
yes
sestro[m] has left #ste||ar ["User left"]
sauravjoshi23 has joined #ste||ar
sauravjoshi23 has quit [Quit: Connection closed]
sauravjoshi23 has joined #ste||ar
sauravjoshi23 has quit [Client Quit]
<hkaiser>
gnikunj[m]: +1
<gnikunj[m]>
hkaiser what's that +1 implying to?
<gnikunj[m]>
Or am I getting things wrong?
<hkaiser>
gnikunj[m]: sorry, I was responding to an old message and realized only then that I already did respond earlier ;-)
<gnikunj[m]>
Got it ;-)
sauravjoshi23 has joined #ste||ar
sauravjoshi23 has quit [Client Quit]
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]