aserio 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/
rod_t has left #ste||ar [#ste||ar]
EverYoung has quit [Ping timeout: 252 seconds]
<github>
[hpx] khuck created fixing_ppc64le_clang_build (+1 new commit): https://git.io/vFefR
<github>
hpx/fixing_ppc64le_clang_build a1d7f53 Kevin Huck: Adding uintstd.h header...
<msimberg>
hkaiser, heller: I also looked into suspending the pus with condition variables, and I guess each thread would have to have its own condition variable? i.e. we can't reuse the condition variable that is already there, because then we'd be waking up suspended threads pus when adding work or unsuspending other pus
<heller>
msimberg: if you do the usual while(condition) cv.wait();
<heller>
you could reuse it
<heller>
but you'd wake up the threads too often, I guess
<msimberg>
I see
<msimberg>
what would be the argument against having separate condition variables for each pu?
<hkaiser>
msimberg: yes, each thread already has it's own CV
<hkaiser>
I showed you where it sits
<msimberg>
hmm, the one in scheduler_base?
<hkaiser>
yes
<msimberg>
but that would be one per pool, no?
<msimberg>
or scheduler
<hkaiser>
let me look
<hkaiser>
I might mix up things
<hkaiser>
but yah, we woul dneed one CV per pu
<msimberg>
hkaiser: ok
<msimberg>
thanks
pree has joined #ste||ar
pree has quit [Read error: Connection reset by peer]
<hkaiser>
jbjnr: yt?
pree has joined #ste||ar
hkaiser has quit [Quit: bye]
aserio has joined #ste||ar
eschnett has quit [Quit: eschnett]
parsa has joined #ste||ar
jaafar has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
<msimberg>
heller: continuing testing with tsan, I get "signal-unsafe call inside of a signal" in hpx::init ... hpx::util::runtime_configuration::init_stack_size (can give you a stack trace if you want)
<msimberg>
real or false positive? or not important?
K-ballo has quit [Remote host closed the connection]
K-ballo1 has joined #ste||ar
K-ballo1 is now known as K-ballo
eschnett has joined #ste||ar
<heller>
msimberg: I'm not sure how reliable tsan is
<heller>
msimberg: signal unsafe sounds correct though
<zao>
I'm still a bit curious as to what kind of clobber resulted in such bogus output from partitioned_vector_subview_test.. https://i.imgur.com/JQ26PR9.png
<zao>
A solid three megabytes of strings from what seems to be the executable.
<msimberg>
heller: ok, thanks
<msimberg>
it also gave some harmless complaints about missing return for example here:
hkaiser has quit [Read error: Connection reset by peer]
aserio has joined #ste||ar
parsa has joined #ste||ar
parsa has quit [Client Quit]
pree has quit [Ping timeout: 255 seconds]
david_pfander has quit [Ping timeout: 240 seconds]
parsa has joined #ste||ar
hkaiser has joined #ste||ar
<hkaiser>
jbjnr: pls contact me once you read this
<heller>
hkaiser: if I read the reviews correctly, they mostly complain that we aren't putting our work into the correct frame
<heller>
Or fail to show the novelty
<heller>
msimberg: ubsan is immensely useful to me
<heller>
msimberg: if feasible, I try to fix the warnings, yes
<heller>
ubsan is overly pedantic sometimes
<heller>
msimberg: why do you find ubsan not helpful?
parsa has quit [Quit: Zzzzzzzzzzzz]
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar
aserio has quit [Ping timeout: 240 seconds]
teonnik has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
<teonnik>
Hi, is it possible to run hpx application using MPI calls directly? I tried running MPI_Allreduce with two processes but the application deadlocks?
<heller>
teonnik: do you also require hpx networking?
<teonnik>
I have an existing MPI program and would like to use HPX kernels for shared memory (on each node) parallelism. I would still like to keep the distributed (MPI) part intact.
<teonnik>
When I installed HPX, I used the -DHPX_WITH_PARCELPORT_MPI=On option if I understood the question correctly.
hkaiser has joined #ste||ar
pree has joined #ste||ar
patg[w] has joined #ste||ar
EverYoung has joined #ste||ar
<pree>
hkaiser : It's good to see your talk at cppcon 2017, It is awesome : )
hkaiser has quit [Read error: Connection reset by peer]
<K-ballo>
he was overwhelmed with emotion to the point of connection error :)
<pree>
:)
<patg[w]>
lol
hkaiser has joined #ste||ar
jbjnr has quit [Read error: Connection reset by peer]
jbjnr has joined #ste||ar
<zao>
Happiness overflow is undefined, optimized out.
<heller>
teonnik: in that case, you should turn networking of completely
<teonnik>
How do I do that?
<heller>
teonnik: -DHPX_WITH_NETWORKING=Off
<teonnik>
Thanks!
<heller>
that's a cmake option
rod_t has joined #ste||ar
<teonnik>
Has anyone built HPX with clang 5.0.0? I get a linking error with boost.regex at the very end. There are also a number of warnings during compilation.
aserio has joined #ste||ar
<zao>
Warnings are probably par for the course.
<zao>
I should give it a try.
<zao>
Did you build Boost with that compiler as well, and do you have any particular flags for building Boost and HPX?
<jbjnr>
is the version I'm currently experimenting with
Vir has joined #ste||ar
<K-ballo>
that much looks ok
<jbjnr>
I cut'n'pasted the contents of the function - not entirely sure they are the right way to do it - I only want a future<result_type> really, but I wasn't sure how to get it.
<jbjnr>
anyway, it's getting called at all that's the trouble
<K-ballo>
yeah I didn't look at the body of the function, it does not participate in the decision of whether the call is viable since it has a proper return type
<K-ballo>
can I paste this in a test or something?
<jbjnr>
let me see if I can put it into the other mini test ...
<jbjnr>
hkaiser: K-ballo has solved my problem with then_execute
<jbjnr>
fyi
<hkaiser>
tks
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
<jbjnr>
hmmm. it's not enough to remove just those two consts - there are more
<jbjnr>
hkaiser: why are the executors const in async and then exeute - etc?
<hkaiser>
shrug
<K-ballo>
those two were enough for the test case
<jbjnr>
yup, but not for my real use-case
<jbjnr>
I touch a bit more code I think.
<jbjnr>
though, actually .... let me try something
eschnett has quit [Quit: eschnett]
<K-ballo>
I'm pretty sure those const are a leftover from the first iteration of Executors, which were pointer wrappers
<teonnik>
The linking issue with clang 5.0.0 was indeed due to build inconsistencies between HPX and Boost. I rebuilt boost and now there are no problems.
<hkaiser>
teonnik: good
<jbjnr>
K-ballo: note that the reduced test where you return {} compilkes, but the original with all the continuation guff doesn't
<K-ballo>
I noticed
<jbjnr>
K-ballo: ok. I had this instead of *this for the executor param in the make_continuation call
<jbjnr>
compiles and runs ok . seems I am one step closer to my goal. thanks very much. One more beer to add to the huge pile that is building for you one day!
<hkaiser>
parsa[w]: yt?
<parsa[w]>
hkaiser: aye
teonnik has quit [Ping timeout: 260 seconds]
<hkaiser>
the error reporting if blaze is not found is broken
<hkaiser>
it says to set 'the follwoing' variables without listing them
<hkaiser>
parsa[w]: even if I set blaze_INCLUDE_DIR to the vcpkg dir it does not find anything
<parsa[w]>
if you're using vcpkg it detects the folder without you having to do anything
<parsa[w]>
i'm clueless about not printing the variable names. though. checking right now