hkaiser 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/
eschnett_ has joined #ste||ar
parsa is now known as parsa_
parsa_ is now known as parsa
parsa is now known as parsa_
parsa_ is now known as parsa
parsa is now known as parsa_
parsa_ is now known as parsa
parsa is now known as parsa_
parsa_ is now known as parsa
eschnett_ has quit [Quit: eschnett_]
parsa is now known as parsa_
hkaiser has quit [Quit: bye]
jbjnr has joined #ste||ar
nikunj has quit [Ping timeout: 268 seconds]
david_pfander has joined #ste||ar
nikunj has joined #ste||ar
david_pfander1 has joined #ste||ar
david_pfander has quit [Ping timeout: 250 seconds]
david_pfander1 is now known as david_pfander
david_pfander has quit [Ping timeout: 240 seconds]
adityaRakhecha has quit [Ping timeout: 256 seconds]
david_pfander1 has joined #ste||ar
eschnett_ has joined #ste||ar
david_pfander1 has quit [Ping timeout: 240 seconds]
hkaiser has joined #ste||ar
eschnett_ has quit [Quit: eschnett_]
eschnett_ has joined #ste||ar
eschnett_ has quit [Quit: eschnett_]
aserio has joined #ste||ar
<Yorlik>
wow - just had a "Compiler out of heap space error"
<Yorlik>
Restarting VS helped
<Yorlik>
I wonder if cl has leaks
<Yorlik>
All these mysteries coming from the depths of the system ...
<K-ballo>
cl runs per TU, so leaks would not accumulate over time
<Yorlik>
That thought made is so mysterious to me :)
<Yorlik>
I have no clue how cl would run out of heap space at one run and not at another.
<Yorlik>
My system runs with 32G RAM and was totally relaxed at the time of the error
<Yorlik>
heller_: Interesting talk - especially this crosstalk issue is haunting our application. GameObjects communicating with other gameobjects and if they gather in a narrow space stuff gets nasty.
jbjnr has quit [Quit: WeeChat 2.3]
<heller_>
hkaiser: I think marvin09 has some memory issues
<Yorlik>
What's especially nasty with this crosstalk issue is, that parallelization across machines increases the latency penalty and it's getting worse the more you try to parallelize. Wish I had a cure against that. We might just and up with some sort of monitoring and adjusting cell sizes depending on contention on either the computing side or the networking side.
<hkaiser>
heller_: ok, we need to tell akheir
<diehlpk_work>
simbergm, Just to confirm, I should use 1.2.1-rc3
<diehlpk_work>
What patches does it include?
<simbergm>
diehlpk_work: no, top of release
<simbergm>
I haven't tagged a new rc
<hkaiser>
heller_: I think I have migration under control now
<hkaiser>
let's talk about this during our call today
<simbergm>
includes all gnuinstalldirs patches I could find
<diehlpk_work>
And all previous patches?
<simbergm>
yeah
<diehlpk_work>
Ok, so it is easy to start the build :) No need to modify my spec file
<diehlpk_work>
We should have the 64 bit packages soon and I will install them on my laptop for testing
<diehlpk_work>
Same for the 32 bit packages on my vm
<jbjnr_>
K-ballo: I suspect they do not need to be copyable
eschnett_ has joined #ste||ar
<jbjnr_>
K-ballo: I did not have time to look at your flatten PR. I think it was merged already. Can you summarize what it was for to save me reading though all the diffs please?
<K-ballo>
jbjnr_: often I set a breakpoint in some code invoked by hpx and then I have to step through 8 or 10 utility frames that deal with the invocation, not it's just one or two
<K-ballo>
s/not/now
<jbjnr_>
cool. Doe it also speeds things up a bit or did it only affet debug builds
<jbjnr_>
s/Doe/Does/
<K-ballo>
I didn't check, I would not expect it, we trust the compiler was inlining all them hard
<jbjnr_>
I think I saw a stack frame about 60 deep when debuging the parcelport. Seemed normal at the time :)
<K-ballo>
yeah, it's crazy
<K-ballo>
I saw some reductions in quickstar examples from 28 -> 8 and things like that
<K-ballo>
deferred_call used to take 4 or 5, now it's just one
<jbjnr_>
lovely
<jbjnr_>
thanks
eschnett_ has quit [Quit: eschnett_]
<jbjnr_>
heller_: when you see this. My question was. Do we really need libcudadevrt. It causes link errors in projects that use HPX with cuda enabled and it shouldn't be exported as an nvcc link flag in HPXTargets.cmake. I'd like to fix it.
<jbjnr_>
gtg
<heller_>
jbjnr_: fix it ;)
<heller_>
hkaiser: weee!
<hkaiser>
jbjnr_: this is a cmake problem, upgrade your cmake version to 3.12.4 (iirc)
<hkaiser>
jaafar: 3.12.2 (see #3616)
<hkaiser>
jbjnr_: ^^
<hkaiser>
sorry jaafar :/
<heller_>
our current PR throughput is pretty awesome ;)
<K-ballo>
I'm almost done, I'm working on what should be the last one
<heller_>
oh no, keep it coming ;)
<K-ballo>
I have to go back to work at some point
david_pfander has quit [Quit: david_pfander]
nikunj97 has quit [Remote host closed the connection]
jaafar has quit [Ping timeout: 250 seconds]
aserio has quit [Quit: aserio]
aserio has joined #ste||ar
<aserio>
hkaiser: yt?
<heller_>
book recommendation: where wiards stay up late
<hkaiser>
aserio: here
<aserio>
hkaiser: Wei was looking for a poster tube he could use
<aserio>
did you have a suggestion as to which one he should take?
<hkaiser>
my office should be open, there should be an empty one on the shelf
<hkaiser>
if none is empty, just consolidate things
<aserio>
hkaiser: ok, I will grab one for him :)
<hkaiser>
thanks
aserio has quit [Ping timeout: 250 seconds]
jbjnr__ has joined #ste||ar
jbjnr_ has quit [Ping timeout: 240 seconds]
jaswanth_rongali has quit [Ping timeout: 240 seconds]
<heller_>
hkaiser: ready whenever you are
jaafar has joined #ste||ar
<hkaiser>
heller_: would now still work?
<heller_>
hkaiser: sure
aserio has joined #ste||ar
daissgr has joined #ste||ar
daissgr has quit [Ping timeout: 240 seconds]
daissgr has joined #ste||ar
<diehlpk_work>
simbergm, the release branch compiled, but the installation path is set to ""
<simbergm>
diehlpk_work: what exactly? make install doesn't work?
<diehlpk_work>
BUILDSTDERR: sed: can't read /builddir/build/BUILDROOT/hpx-1.2.1-1.fc30.x86_64/usr/lib64/openmpi/lib/cmake/HPX/templates/hpxcxx.in: No such file or directory
<diehlpk_work>
BUILDSTDERR: sed: can't read /builddir/build/BUILDROOT/hpx-1.2.1-1.fc30.x86_64/usr/lib64/openmpi/lib/cmake/HPX/templates/hpxrun.py.in: No such file or directory
<parsa_>
is hpx::run_as_hpx_thread still a things or should we use hpx::threads::run_as_hpx_thread?
<parsa_>
thing*
parsa_ is now known as parsa
<heller_>
hkaiser: is you migration fix branch running on top of latest master?
<heller_>
parsa: I think both are a thing
<heller_>
parsa: better check the code
<heller_>
parsa: what are you after?
<parsa>
hpx::run_as_hpx_thread didn't compile so i had to ask
<hkaiser>
heller_: don't think so
<heller_>
good
<heller_>
saw a bug which was supposed to be fixed by now ;)
<simbergm>
diehlpk_work: err, is that the spec file calling sed?
<hkaiser>
aserio: is Ali around?
<aserio>
hkaiser: yes
<Yorlik>
I'm getting the following error: "LNK1181: cannot open input file 'hpx_lua_engine_component.lib' ". I see the dll (hpx_lua_engine_component.dll) has been created, but not an import library, unlike when compiling other dlls.. What did I miss?
<hkaiser>
could you ask him to get online here, pls?
<aserio>
something about rostam?
<diehlpk_work>
simbergm, Yes, we need to replace python2 by python3, because new fedora packages are not allowed to depend on python2
<K-ballo>
Yorlik: what's this hpx_lua_engine_component? sounds like a target of yours
<hkaiser>
Yorlik: HPX_COMPONENT_NAME=... and HPX_COMPONENT_NAME_STR="..."?
<Yorlik>
Yes it is
<K-ballo>
did you export it?
<Yorlik>
Its in the same CMake file
<hkaiser>
aserio something about fortytwo
<K-ballo>
wait, do you mean import library in the win32 sense, or in the cmake sense?
<aserio>
hkaiser: ah, ok
<Yorlik>
Is exporting mandatory with HPX components?
<aserio>
he should join in a second
<simbergm>
diehlpk_work: it's looking in the wrong place for those files
<simbergm>
maybe something else is off as well but the path given to sed is at least wrong
<hkaiser>
Yorlik: HPX components have to export some (internal) symbols in order to to be recognized as such
<hkaiser>
aserio: thanks
<Yorlik>
IC - seems I gotta RTFM some more. Thanks for the heads-up :)
<hkaiser>
Yorlik: please look at the accumulator examples
<hkaiser>
there you have minimally working components
<Yorlik>
Will do! I am using default CMake targets with hpx_setupo_target
<hkaiser>
right, you need to add some special code
<diehlpk_work>
simbergm, Ok, I will have a look what is going wrong.
<diehlpk_work>
This was working before and I will check what exactly changed
<simbergm>
diehlpk_work: I'll have a look tomorrow as well if I might still have messed something up with the patches
<diehlpk_work>
Sure
akheir has joined #ste||ar
<heller_>
Yorlik: how are trying to link against it? how are you building it?
<akheir>
hkaiser: looking for me?
<Yorlik>
heller_: I am using a CMake project inside VS. Creating CMake targets and modifying them with hpx_setup_target
<heller_>
Yorlik: pleas provide a small, self contained, reproducible testcase
<Yorlik>
I'll do
<hkaiser>
akheir: Jason sent an email asking a bunch of questions wrt fortytwo
<hkaiser>
would you mind answering, please?
<akheir>
sure, I'll do right away
jbjnr has joined #ste||ar
<jbjnr>
hkaiser: not a cmake problem. I am using 3.13 (arch linux always new stuff)