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/
nanmiao11 has joined #ste||ar
shahrzad_ has joined #ste||ar
shahrzad has quit [Ping timeout: 240 seconds]
bita has quit [Ping timeout: 260 seconds]
bita has joined #ste||ar
hkaiser has quit [Quit: bye]
Yorlik has quit [Ping timeout: 272 seconds]
nanmiao11 has quit [Ping timeout: 245 seconds]
shahrzad_ has quit [Quit: Leaving]
bita has quit [Ping timeout: 244 seconds]
Yorlik has joined #ste||ar
hkaiser has joined #ste||ar
jbjnr has joined #ste||ar
<jbjnr>
hkaiser, yt?
<hkaiser>
here
<jbjnr>
do you have a few minutes free for a possible video chat?
<hkaiser>
jbjnr: I can confirm that this is a bug - as discussed, we do not clear the pointer tracking data in the preprocessing archive before repeatedly serializing things after the future became ready
<hkaiser>
I will try to come up with a solution
<hkaiser>
jbjnr: please see #5012
<jbjnr>
Thanks hkaiser - sorry I got dragged away. Every time I sit down to work, something happens and I'm not getting a lot done, so I really appreciate your input on this. cheers
<hkaiser>
jbjnr: pls let me know if this fixes the issue
<ms[m]>
it might be overwriting the non-generated file in the install dir
<hkaiser>
ahh
<hkaiser>
why does it happen for the installtion step only?
<K-ballo>
the build interface will have two headers reachable by the same name, you'll get whichever is first in the include directories list
<hkaiser>
true
<hkaiser>
or its overwritten during installtion...
<K-ballo>
it is overwritten during installation
<hkaiser>
makes sense
<K-ballo>
both headers are installed to the same place
<hkaiser>
thanks guys
<hkaiser>
that's subtle
<K-ballo>
it could be detected/rejected
<K-ballo>
odd that cmake won't reject during install
<hkaiser>
right, checking whether the generated name will conflict
<ms[m]>
I suppose cmake wouldn't be smart enough to detect that, it's after all meant to overwrite existing installations
<ms[m]>
but we could indeed detect that
weilewei has joined #ste||ar
<gnikunj[m]>
hkaiser: should we preprint the paper, now that it has gotten accepted? I was talking to diehlpk_work and he told me about the advantages of preprinting.
<hkaiser>
gnikunj[m]: feel free
<gnikunj[m]>
hkaiser: alright. I'll complete the final draft today and ask Keita if we can go for arxiv preprint as well.
<hkaiser>
thanks
<diehlpk_work>
ms[m], Have you done some sclaing runs on Daint recently?
<K-ballo>
that symbol mapping is what IWYU was missing to be actually useful
<K-ballo>
ms[m]: can we add IWYU to one of our builders? probably something we have control over so we can just provide the binary
<rori>
👍️
<ms[m]>
K-ballo: absolutely
<K-ballo>
I'll start working on the mappings
<ms[m]>
Did you try it recently then? It's been quite useless so far when I've tried but sounds like it might not be anymore?
<ms[m]>
👍
<ms[m]>
Thank you
<K-ballo>
I tried it years ago, it was absolutely useless
<K-ballo>
between the forward declarations and the lack of mappings
<gonidelis[m]>
ms[m]: did you made the changes last month on the directories format? like in full, parallel and core?
<gonidelis[m]>
make^^
<gonidelis[m]>
ms[m]:
<gonidelis[m]>
(sorry for the double tag0
<hkaiser>
gonidelis[m]: yes, ms[m] did that
<gonidelis[m]>
i have a question
<gonidelis[m]>
what is this `libs/full/include/include/hpx/algorithm.hpp` file about?
<gonidelis[m]>
do we like put every algorithm we adapt here?
<gonidelis[m]>
hkaiser: the thing is that declaring `using hpx::parallel::transform;` pups a conflict
<gonidelis[m]>
Did we use to do use that statement under `hpx::` anywhere else?
<gonidelis[m]>
(commenting it out relieves the problem, but that's not the solution)
<ms[m]>
freenode_gonidelis[m]: if you've added `hpx::transform` as a cpo then removing the using statement is the solution
<gonidelis[m]>
ohhh ok... So it's like the inverse ;p ? We don't add the adapted algorithms, rather than we remove them from this list ?
<gonidelis[m]>
ms[m]: ^^
<ms[m]>
we added the using statements just to get the algorithms into the top-level hpx namespace, but the goal is to have the algorithms to start with in `hpx` without using statements
<gonidelis[m]>
and cpo's provide that for us, right?
<ms[m]>
not sure I follow... we had all of them in the list, but as we've added cpos we just moved them directly to `hpx` at the same time
<ms[m]>
*added them directly to `hpx`, not moved
<ms[m]>
and then the old ones in `hpx::parallel` get deprecated
<gonidelis[m]>
ok ok... my bad. I get it. Thank you very much B)
<gonidelis[m]>
yeah cool. Got it ;)
<ms[m]>
no problem :)
<gonidelis[m]>
yeah I now get why there was the conflict.
<gonidelis[m]>
good
<gonidelis[m]>
btw, could you please the code, full, parallelism separation?
<gonidelis[m]>
what's the idea behind that?
<gonidelis[m]>
ms[m]: ^^
<ms[m]>
the idea is that we could have users only link to part of hpx, someone who doesn't want the full hpx runtime could just use hpx_parallelism to get all the local parallelism and concurrency
<ms[m]>
core is unlikely to be useful on its own to many people, but it just contains utilities and the base coroutines/thread pool functionality
<ms[m]>
none of this is exposed through cmake yet though
<ms[m]>
full is just a bad name for "the rest of hpx on top of the local parallelism and core"
<gonidelis[m]>
is it like we want to make HPX focused on its parallel part?
<gonidelis[m]>
haha...
<gonidelis[m]>
from the user side ^^
<ms[m]>
not so much focus, but just provide a smaller subset for those not interested in the distributed parts
<ms[m]>
the distributed parts are still essential to the "full hpx experience" though
<gonidelis[m]>
ohhh... I get it. That's a great change then.
<gonidelis[m]>
I am willing to help if necessary and when I finally adapt my code to those ;p
<gonidelis[m]>
them^^
<gonidelis[m]>
ms[m]: Did we remove the intermediate `util::` namespace in some places?
<gonidelis[m]>
or I don't know ^^ . The compiler complains when i type sth::util::sth_else. it wants it out. Why is that?
<gonidelis[m]>
Did we just move certain things under util?
<K-ballo>
some stuff moved out, like say tuple
<K-ballo>
you can see it in the git history
<gonidelis[m]>
yeah I know that.
<gonidelis[m]>
the thing is there was this hpx::util::invoke() call
<gonidelis[m]>
and compile now wants a plain `hpx::invoke()`
<K-ballo>
did invoke move too? I don't think so
<gonidelis[m]>
but the call was already under `namespace util{}`
<K-ballo>
`hpx::invoke()` would still be wrong even under namespace util, unless
<K-ballo>
unless we have a messed up using namespace util; lose
nanmiao11 has joined #ste||ar
<K-ballo>
which may very well be, there were some signs a few days ago
<gonidelis[m]>
ok let me check it. seems like I 've been careless here
<gonidelis[m]>
thanks for the heads up though
<gonidelis[m]>
BD
<K-ballo>
there is an include pulling `invoke` out of util
<gonidelis[m]>
where?
<gonidelis[m]>
where did you ecnounter that?
<K-ballo>
include/hpx/functional.hpp
<K-ballo>
I find it a bit odd, IIRC those are only supposed to be included by users, and not hpx itself
<gonidelis[m]>
users should include `invoke` ?
<K-ballo>
no
<gonidelis[m]>
what "those" are supposed to be included by users?
<K-ballo>
_only_ supp... headers under hpx/include/
<gonidelis[m]>
ok seems reasonable
<gonidelis[m]>
why do we have this call `f` as an l-value?