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/
hkaiser has quit [Quit: bye]
bita has quit [Ping timeout: 264 seconds]
<mdiers[m]>
<hkaiser "'m not 100% sure this will fix y"> How right you are. See pr.
<gonidelis[m]>
hkaiser: there are discrepancies between the detail/sequential_find and algorithm/sequential_find
<gonidelis[m]>
I don't think you are using the detail one at all... although that's the one you created as part of your adaptation pr
<gonidelis[m]>
hkaiser: again the new sequential_find lacks the projection utility
<gonidelis[m]>
although the sequential ranges overloads may use it
hkaiser has joined #ste||ar
<hkaiser>
mdiers[m]: yt?
<mdiers[m]>
hkaiser: yes
<hkaiser>
hey
<hkaiser>
what HPX facility/API is causing things to fail? Do you happen to know that?
<mdiers[m]>
For example, you mean the hpx::for_loop(...)?
<hkaiser>
yes
<hkaiser>
so it happens inside a for_loop?
<mdiers[m]>
Yes, within different for_loop() with a special executor, as you can also see from the callstack.
<hkaiser>
mdiers[m]: could you show me this for_loop?
<hkaiser>
special executor? can I see that one?
<mdiers[m]>
One moment please, I have just a small technical problem to get to the things.
<hkaiser>
mdiers[m]: is the execution policy sync or async?
<hkaiser>
gonidelis[m]: not sure I understand what you mean
<mdiers[m]>
hkaiser: added a comment to the gist
<hkaiser>
k
<hkaiser>
mdiers[m]: I'm a bit clueless, honestly
<mdiers[m]>
And the whole thing is called in a hpx::components::component_base<>.
<gonidelis[m]>
hkaiser: did you see #5119 ?
<hkaiser>
yes, looks fine
<hkaiser>
except for why is Pred taken by value and Proj by forwarding reference
<gonidelis[m]>
hkaiser: oh
<gonidelis[m]>
hkaiser: what do we want to pass to `hpx::util::invoke`?
<gonidelis[m]>
refs or values?
<hkaiser>
gonidelis[m]: the invoke is called in a loop, so you can't forward or move
<mdiers[m]>
hkaiser: As said, it can take minutes but also hours until the segfault. Increased on our nodes with a *larger* core count: dual Xeon Gold 6240 or EPYC 7401P.
<mdiers[m]>
* hkaiser: As said, it can take minutes but also hours until the segfault. Increased on our nodes with a _larger_ core count: dual Xeon Gold 6240 or EPYC 7401P. Container distribution is ubuntu 20.04.
<hkaiser>
mdiers[m]: could you try running this loop with just hpx::execution::par (no .on().with())?
<hkaiser>
I would like to make sure it's not the executor giving us trouble here
<mdiers[m]>
hkaiser: The performance breaks down then, but I'll give it a try.
<hkaiser>
yah sure, perf might be worse, but functionally it should be fine
<hkaiser>
thanks
<hkaiser>
gnikunj[m]: have you seen ms[m]' comments to your PR by any chance?
<gnikunj[m]>
hkaiser I did. I'll update it tonight (in a few hours)
<hkaiser>
gnikunj[m]: perfect, thanks!
<mdiers[m]>
hkaiser: The test is started, performance is now only 1/4. I will report as soon as I know more. Can only be a matter of hours.
<hkaiser>
thanks!
<mdiers[m]>
hkaiser: I have to thank for the support.
<mdiers[m]>
hkaiser: It was only minutes. I have attached a callstack to the pr.
<hkaiser>
thanks
akheir has joined #ste||ar
<mdiers[m]>
hkaiser: I will be away again for about 2 hours.
jpinto[m] has quit [Quit: Bridge terminating on SIGTERM]
tiagofg[m] has quit [Quit: Bridge terminating on SIGTERM]
klaus[m] has quit [Quit: Bridge terminating on SIGTERM]
teonnik has quit [Quit: Bridge terminating on SIGTERM]
parsa[m] has quit [Quit: Bridge terminating on SIGTERM]
k-ballo[m] has quit [Quit: Bridge terminating on SIGTERM]
pedro_barbosa[m] has quit [Quit: Bridge terminating on SIGTERM]
ms[m] has quit [Quit: Bridge terminating on SIGTERM]
mdiers[m] has quit [Quit: Bridge terminating on SIGTERM]
rori has quit [Quit: Bridge terminating on SIGTERM]
gonidelis[m] has quit [Quit: Bridge terminating on SIGTERM]
gnikunj[m] has quit [Quit: Bridge terminating on SIGTERM]
klaus[m] has joined #ste||ar
gonidelis[m] has joined #ste||ar
rori has joined #ste||ar
gnikunj[m] has joined #ste||ar
jpinto[m] has joined #ste||ar
mdiers[m] has joined #ste||ar
heller1 has joined #ste||ar
tiagofg[m] has joined #ste||ar
ms[m] has joined #ste||ar
teonnik has joined #ste||ar
pedro_barbosa[m] has joined #ste||ar
parsa[m] has joined #ste||ar
k-ballo[m] has joined #ste||ar
heller1 has quit [Quit: Idle for 30+ days]
bita has joined #ste||ar
<gnikunj[m]>
hkaiser: done!
<hkaiser>
gnikunj[m]: thanks a lot!
<hkaiser>
gnikunj[m]: yt?
<gnikunj[m]>
hkaiser: here
<hkaiser>
hey
<hkaiser>
thanks for the docs additions
<gnikunj[m]>
Hey! Anything wrong with the PR again?
<hkaiser>
have you seen the other comments?
<gnikunj[m]>
Ohh I thought that was for you. What do I need to do there?
<hkaiser>
I'd appreciate it if you had the time to address those
<gnikunj[m]>
sure I will. What does those exactly say though? I've missed the bus to the modular design of HPX and don't very well understand them :/
<hkaiser>
ok
<hkaiser>
well, I can try finding time to do it
<gnikunj[m]>
I can do it if you tell me what that exactly means
<hkaiser>
two of the comments just ask to revert that particular change
<hkaiser>
the last one asks to wrap the resilience related headers with an #ifdef in order to make hip work (and there is a hpx builder running to verify)
<gnikunj[m]>
aah, so I did understand them correctly. Alright, will make the change!
<gnikunj[m]>
hkaiser: do I need to wrap the whole document in the ifdef?
<hkaiser>
have look at how it's done in other places