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/
khuck has quit [Remote host closed the connection]
khuck has joined #ste||ar
khuck has quit [Read error: Connection reset by peer]
khuck has joined #ste||ar
hkaiser has quit [Quit: bye]
K-ballo has joined #ste||ar
nanashi55 has quit [Ping timeout: 252 seconds]
nanashi55 has joined #ste||ar
eschnett has quit [Quit: eschnett]
nikunj has joined #ste||ar
david_pfander has joined #ste||ar
nikunj has quit [Remote host closed the connection]
heller has quit [Read error: Connection reset by peer]
Vir has quit [Ping timeout: 252 seconds]
heller has joined #ste||ar
david_pfander1 has joined #ste||ar
david_pfander has quit [Read error: Connection reset by peer]
<khuck>
heller: hkaiser: I just built master and got tons of warnings
<khuck>
but it built
<khuck>
with gcc
<heller>
khuck: did my sanitizer thing help?
<khuck>
heller: I don't have time to wrestle with that right now
<khuck>
sorry :(
<heller>
ok
<heller>
sure, np
<heller>
I think this bug is just a side effect of something really bad going wrong
<heller>
the sanitizers should catch that quickly
<khuck>
my valgrind session went for hours and built a very large suppression list. but I didn't find the problem.
<hkaiser>
heller: ok
<hkaiser>
khuck: what warnings?
<khuck>
hkaiser: instead of pasting a big thing here, how do I create a link in github for you to see?
<hkaiser>
heller: but we should merge #3472 anyways
ste||ar-github has joined #ste||ar
<ste||ar-github>
[hpx] hkaiser opened pull request #3472: Attempting to work around recent clang test compilation failures (master...clang_test_workaround) https://github.com/STEllAR-GROUP/hpx/pull/3472
<hkaiser>
if we silence it for one platform it shows up for another one
<hkaiser>
no, that warning was there for a long time
<hkaiser>
khuck: btw, I just got access to your systems
<khuck>
have fun!
<hkaiser>
;-)
<khuck>
hkaiser: try not to get me fired
<hkaiser>
khuck: ok, will try
<khuck>
the clang build doesn't give those errors, just the gcc builds (for the phylanx buildbot servers)
<khuck>
^errors^warnings
<hkaiser>
khuck: I know
<khuck>
appeared three days ago, after fix_3439_2 was merged
<khuck>
(which you also probably already know)
<hkaiser>
khuck: I think this warning was there for month, if not longer
<khuck>
not on master. The build from 4 days ago had 1 warning.
<khuck>
this is gcc 7.1 on x86_64
<hkaiser>
khuck: then I have no idea
eschnett_ has joined #ste||ar
<heller>
khuck: yes, that warning is very annyoing
<heller>
it's been there since almost a year or two now...
<khuck>
heller: funny, I didn't see it until today.
<heller>
I really hate compilers
<heller>
I spent all day compiling
<heller>
and trying to figure out a performance problem
<heller>
so, I narrowed it down that something isn't inlined properly. So I manually inlined it
<heller>
however, it could not have been verified by my colleagues. The speed stayed the same
<heller>
now, just before I loose all my sanity, I compiled without the cray compiler wrapper
<khuck>
heller: would you rather write assembly? :)
<heller>
and the stuff is 50 seconds faster
<heller>
TFW?
<khuck>
you can ask the wrapper to tell you what it is doing
<heller>
which is nothing suspicous
<heller>
just setting -march=core-avx2
<khuck>
cc --cray-print-opts=all
<khuck>
cc --cray-print-opts=cflags
<khuck>
or -craype-verbose
<heller>
yes, I know that one
<heller>
does linking against libraries affect performance?
<K-ballo>
maybe if you have dynamically initialized globals or something
<heller>
or change the behavior of the inliner?
<heller>
it was clearly not inling functions where my reference implementation did
aserio has quit [Quit: aserio]
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
<hkaiser>
heller: the paper, can you do that asap?
<heller>
hkaiser: yes, it's on my schedule for tomorrow
<hkaiser>
ok, thanks - #12 is the last comment that needs addressing, I believe
<heller>
ok
<heller>
just for confirmation, it is the one which complains about missing I/O times and improper reporting of speedup etc, right?
<hkaiser>
yah
<heller>
ok
<heller>
not sure yet what to write there ...
<hkaiser>
heller: I think we could clarify that the times are plain compute, no io times have been collected
<hkaiser>
so no time to solution timings are available
<heller>
yeah
<hkaiser>
could be also added to future work section
<khuck>
heller: you could mention that we used the burst buffer, and saw some benefits with staging? Or is that text in there already?
<hkaiser>
khuck: good point, I think this is not in there
<khuck>
hkaiser: even if we had performance data with/without staging, I'm not sure we still have it around, or measured it carefully. Unless Thomas did