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/ | GSoD: https://developers.google.com/season-of-docs/
nikunj has quit [Remote host closed the connection]
hkaiser has quit [Quit: bye]
nikunj has joined #ste||ar
<K-ballo> is Rebecca here?
<simbergm> diehlpk_work: in general yes, but if it's more hassle and I can't help much I can skip it
<simbergm> if I'm more useful later I'll join then instead
<simbergm> K-ballo: I don't think so, she went by USTOBRE at some point
<simbergm> jbjnr: I think your sliding_semaphore version of the future_overhead benchmark needs fixing
<simbergm> it's not guaranteed to wait for all futures
<simbergm> not sure if you want to keep it since you have the limiting executor doing pretty much the same thing
<simbergm> I think you'd need two counters to do it correctly (latch and sliding_semaphore or just two atomic counters)
rori has joined #ste||ar
<simbergm> heller, jbjnr: should we have a call for the cscs course in time this time so we know what still needs to be done? like next week?
hkaiser has joined #ste||ar
<heller> simbergm: that would be good
<hkaiser> simbergm: what do you think about #4068? I know its a hack, so any better ideas would be welcome
<simbergm> heller: good
<simbergm> hkaiser: either changing the ifdef (if that works) or boost::spinlock are both better I think
<hkaiser> simbergm: I ran into similar missing #includes for the collectives stuff
<hkaiser> not only spinlock
<hkaiser> this will be a problem for all modules that have source files and that depend on the remaining 'runtime-blob'
<simbergm> mmh, that's why I'd like to move the massive runtime-blob into a module already now
<hkaiser> nod
<simbergm> it interferes with everything though
<simbergm> especially the cmake branch
<hkaiser> right
<hkaiser> I think my hack provides a simple enough intermediate solution
<simbergm> adding a special-case target_include_directories like that is I think a good, minimally hacky solution
<hkaiser> that does not interfere with anything
<simbergm> yeah, definitely
<hkaiser> we could enable it on a module by module bases, but then we would have to go back and touch on all related modules later on
<simbergm> so yeah, sorry if I was being dismissive, I think it's a good solution where we can't do anything else yet; for #4068 I hope we can avoid it
<hkaiser> not sure this is a good idea
<simbergm> hold on, you didn't have to do this for collectives, right?
<hkaiser> yes, I needed it there
<simbergm> link?
<hkaiser> well, I'm talking about #4068, what other options do you have in mind?
<simbergm> wait, confused...
<hkaiser> yah, me too ;-)
<hkaiser> barrier is a component, so needs to see all the related header files
<hkaiser> and many more things
<simbergm> ok, right, I just didn't see any extra (target_)include_directories there
<hkaiser> I added it globally in the AddModule macro
<simbergm> #4069 is collectives, #4068 is the spinlock/logging issue
<hkaiser> #4069 depends on #4068
<simbergm> ah ok
<simbergm> ookay, sorry for being slow, I didn't notice that dependency
<hkaiser> let me add a comment
<hkaiser> simbergm: sorry for being sloppy here
<simbergm> yes, let's go for that then, the dependency check should still hopefully catch circular dependencies which is the important part
<hkaiser> it will
<hkaiser> we kinda chip at the big blob from two ends here
<hkaiser> from below and from above
<simbergm> indeed
<simbergm> thanks!
<simbergm> if parsa still has time to check the other fix for the logging module that would be great
<hkaiser> ok, so let's get #4068 in asap - we can work on the spinlock issue in any case
<hkaiser> yes, I'll ask him today
<hkaiser> btw, we have gotten HPX to run on summit yesterday
<hkaiser> no issues at all
<simbergm> wee, nice!
<simbergm> I think jbjnr has had it running there recently as well
<hkaiser> ahh ok
<simbergm> I merged #4068 btw
<hkaiser> did he get his libfabrics stuff running as well?
<simbergm> not sure...
<simbergm> I'll do #4064 next if I finally managed to get all the right tests ifdefed out, then the functional module, then your PRs
<hkaiser> ok, I need to touch things up still anyways
<simbergm> any new thoughts on #4026? let it sit for a while?
<hkaiser> give me a day or two, please - I have not had any time to think about this
<heller> libfabric might be interesting, as they have infiniband there, IIRC
<hkaiser> heller: have we used boost context on power before?
<hkaiser> do you remember?
<simbergm> hkaiser: no worries at all, take your time
<heller> hkaiser: yes, we did
<heller> hkaiser: IBM used to only use boost context
<hkaiser> heller: ok, thanks
<hkaiser> apparently the fallback does work on summit as well ;-) (ucontext and friends)
<heller> if you need help there, have the student ask me
<heller> of course it does
<hkaiser> heller: I'll cc you on the conversation, thanks
<heller> does it perform good, is the other question ;)
<heller> I might be able to better respond here on IRC
<heller> hkaiser: I hope you make some verifications on the performance ;)
<heller> a good start is always to compare stream benchmark results
<hkaiser> heller: trying to get hello_world running, currently ;-)
<hkaiser> THAT runs reallllly fast - lol
<zao> I should try building HPX on our clusters again some day. It's supposed to work, I hear :)
<hkaiser> zao: WHAT??? you didn't build HPX recently? ;-)
<zao> Last attempt was on Windows, where the tests/examples suffered from modules :)
<zao> Been too busy with actual work at work.
<heller> hkaiser: hello_world is the most awesome program, I hear it's a candidate for zetascale ;)
<hkaiser> zao: it never happened before - and yet again, huh?
hkaiser has quit [Quit: bye]
mdiers_ has quit [Ping timeout: 246 seconds]
mdiers_ has joined #ste||ar
<diehlpk_work> K-ballo, Rebecca will be around in ric while she is working on the docs
<diehlpk_work> If you want to discuss with her the easiest way would be to send her an e-mail
aserio has joined #ste||ar
<simbergm> aserio, hkaiser, jbjnr, heller meeting? completely forgot...
<heller> simbergm: yes
hkaiser has joined #ste||ar
bita_ has joined #ste||ar
bita has quit [Ping timeout: 276 seconds]
weilewei has joined #ste||ar
aserio has quit [Quit: aserio]
aserio has joined #ste||ar
weilewei has quit [Remote host closed the connection]
weilewei has joined #ste||ar
aserio has quit [Ping timeout: 276 seconds]
aserio has joined #ste||ar
weilewei has quit [Remote host closed the connection]
rori has quit [Quit: bye!]
aserio has quit [Ping timeout: 264 seconds]
weilewei has joined #ste||ar
<parsa> simbergm: do you want me to test https://github.com/STEllAR-GROUP/hpx/issues/4067#issuecomment-527970973 or is #4070 good enough?
<simbergm> parsa: yes, please
<simbergm> I think we'll end up with cyclic dependencies otherwise
<simbergm> if that doesn't work would you mind making our spinlock a boost spinlock instead?
<hkaiser> simbergm: concurrency or timing do not depend on logging, do they?
<simbergm> logging -> concurrency -> errors -> logging
<simbergm> let's see, circleci should tell us soon
<hkaiser> we would have seen that already as our cyclicity checking relies on real header files, while the cmake dependencies are maintained by hand indepently
<hkaiser> the dependency on concurrency we need to specify because of the runtime-blob that is pulled in by logging
aserio1 has joined #ste||ar
<simbergm> if logging pulls in the runtime blob I've done something wrong
<simbergm> it shouldn't be doing that
<hkaiser> well, apparently it does, at least on mac
<hkaiser> compiling logging.cpp was looking for a header from hpx/concurrency
<hkaiser> and from hpx/timing
aserio1 is now known as aserio
<simbergm> right, it pulls in concurrency but not the whole runtime blob, and only on non-windows/linux
<simbergm> hence the suggestion to use boost spinlock instead
weilewei has quit [Remote host closed the connection]
<heller> hmm, wei is gone instead
<heller> already
aserio has quit [Ping timeout: 276 seconds]
weilewei has joined #ste||ar
aserio has joined #ste||ar
<hkaiser> heller, simberg: just removing transfer_action gives us a 10% compilation speedup of the main core library (including linking) on my machine (74s vs 65s)
<hkaiser> there is a lot more code that could be removed if networking is disabled
<heller> hkaiser: try the unit tests or examples or so
<hkaiser> sure
<heller> I suspect that this will give the real boost
<diehlpk_work> heller, git log will give me the names of the authors of each file
<diehlpk_work> How will I get the names to each of the cpp files and hpp files?
<diehlpk_work> And all names even once
<diehlpk_work> If you have any idea to add the names from the git log to the files of octotiger, I would be happy to get the script doing this?
<heller> I don't have such a script
<heller> You initiated the change
<heller> BTW, changing licenses in the aftermath theoretically requires the consent of all authors. not that I'm objecting in general, just saying...
aserio has quit [Ping timeout: 250 seconds]
hkaiser has quit [Quit: bye]
<zao> I (jokingly) object!
<zao> Jokes aside, I'm fine with whatever you would want to do with my few contributions.
<heller> zao: it's about octotiger, not hpx itself
<zao> Oh. Carry on then :)
aserio has joined #ste||ar
aserio has quit [Quit: aserio]
hkaiser has joined #ste||ar
weilewei has quit [Remote host closed the connection]