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/
diehlpk_mobile has joined #ste||ar
nikunj has joined #ste||ar
hkaiser has quit [Quit: bye]
nikunj has quit [Remote host closed the connection]
jaafar has quit [Quit: Konversation terminated!]
jaafar has joined #ste||ar
<jbjnr> simbergm: yt?
<simbergm> jbjnr: yep
<jbjnr> in the scheduler, the call to select_active_pu(l, data.schedulehint.hint); (+friends) - it's there to support cores being shutdown or something yes?
<simbergm> yep, exactly
<simbergm> should do nothing if elasticity is off
<jbjnr> so it would be safe for me to only call it, if a mode flag is set?
<jbjnr> aha ok
<simbergm> the check is done inside
<jbjnr> ta
quaz0r has quit [Ping timeout: 245 seconds]
quaz0r has joined #ste||ar
rori has joined #ste||ar
daissgr has joined #ste||ar
hkaiser has joined #ste||ar
<hkaiser> simbergm: yt?
<simbergm> hkaiser: yep, here
<hkaiser> hey Mikhal
<hkaiser> I noticed the other day that circleci runs for the stable tag as well
<hkaiser> would you know if we can avoid this? there is enough pressure on circleci without it
<simbergm> ah, indeed, that's not necessary
<simbergm> yeah, it should be possible to exclude it, I'll look into it
<hkaiser> thanks
<hkaiser> I don't know anything about how circleci works :/
<hkaiser> so this would be much appreciated
<simbergm> np
<simbergm> hkaiser: #4010 should do it...
<hkaiser> simbergm: that was quick !
<hkaiser> cool, thanks!
<simbergm> let's hope it works, it wouldn't be the first time the config surprises me...
<hkaiser> sure
<hkaiser> we have to merge it in order to see whether it works, pls go ahead
diehlpk_mobile has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
hkaiser has quit [Quit: bye]
<jbjnr> simbergm: just fyi - https://pasteboard.co/IqPRQDy.png very small overhead, but still measureable!
<simbergm> jbjnr: cool, yeah, that's definitely more than it should be
<simbergm> probably moving the check outside the function would get rid of some of it
<jbjnr> I had a quick look, but the mode flag isn't stored in the scheduler ...
<jbjnr> the atomic load/vector access is all it is
<jbjnr> adding an elasticity flag to the scheduler itslef would be ok by me
<simbergm> you mean an explicit flag which is not in the scheduler mode?
<simbergm> the scheduler_mode is stored in the scheduler, just defined in scheduler_base
<jbjnr> I was confused. The pool holds the elasicity - not the scheduler - so the scheduler can't get it easily. ignore me
<simbergm> huh? I feel like we're talking about different things...
diehlpk has joined #ste||ar
<jbjnr> we were in a way. I had imagined that the scheduler would have an 'elasticity' flag in it, but the pool is created with that, and then the scheduler gets each thread marked accordingly. I wanted to just say if(elastic) blah blah in the scheduler
<jbjnr> my main concern was that 99.9% of the time we are not using the elastic flag, so it ought to be free/cheap
hkaiser has joined #ste||ar
<K-ballo> I see having format as a module allowed us to drop the benchmarks link hack
aserio has joined #ste||ar
<simbergm> jbjnr: yeah, agreed that is should be close to free
<jbjnr> I'll look at it properly tonight
<jbjnr> doing a bunch of benchmakring of schedulers again
<jbjnr> need moddycamel merged if poss :)
<simbergm> but the modes are stored padded per thread so accessing them should be close to free...
<simbergm> are you sure it's not the virtual function call to select_active_pu?
<jbjnr> not sure about anything
<jbjnr> hance my benchmarking
<jbjnr> ^hence
<simbergm> not sure if that gets optimized away
<simbergm> right, good idea with separating that out
<simbergm> tests pass now!
<simbergm> we can probably merge that
aserio has quit [Ping timeout: 276 seconds]
<zao> On Windows too? :)
<hkaiser> zao: are there known WIndows problems with the MoodyCamel stuff?
<zao> I don’t know what this is, just that tests i and Yorlik built earlier this week from stable couldn’t link right due to lack of HPX symbols not pulled in.
<zao> If this is unrelated to that ignored issue, well, meh
<jbjnr> PRs aren't in stable, so don't worry about my stuff.
<hkaiser> ok, thanks for the elaboration
<hkaiser> I'll leave it to Yorlik to complain afterwards ;-)
<hkaiser> simbergm: I accidentially pushed a change to master
<hkaiser> I apologize, this was intended to go on a branch :/
<simbergm> "accidentally"?
<simbergm> no worries :P
<hkaiser> no really - I blame Adrian, he distracted me while I was doing things ;-)
<diehlpk> So Adrian is our hero if things go well and our scapegoat if not ?
<simbergm> I believe that :)
<simbergm> hkaiser: speaking of adrian, do you think he could arrange a stellar t-shirt for shoshana?
<simbergm> we realized she never got one!
diehlpk has quit [Ping timeout: 272 seconds]
<simbergm> hkaiser: you did forget to blame heller for it...
<hkaiser> simbergm: absolutely, pls ask her to send her contact information and preferred t-shirt size to him
<hkaiser> simbergm: I didn't know Shoshana was still around
<simbergm> thanks, I'll tell her to do that
<simbergm> she wasn't around for a while, but she came back
<simbergm> she's just not working on hpx
<hkaiser> ok
eschnett has joined #ste||ar
aserio has joined #ste||ar
eschnett has quit [Quit: eschnett]
rori has quit [Quit: bye]
jaafar has quit [Ping timeout: 276 seconds]
aserio has quit [Ping timeout: 276 seconds]
aserio has joined #ste||ar
jaafar has joined #ste||ar
jaafar_ has joined #ste||ar
hkaiser has quit [Quit: bye]
jaafar has quit [Ping timeout: 248 seconds]
nikunj97 has quit []
jaafar_ has quit [Ping timeout: 246 seconds]
jaafar_ has joined #ste||ar
jaafar_ has quit [Ping timeout: 246 seconds]
hkaiser has joined #ste||ar
aserio has quit [Quit: aserio]
jaafar has joined #ste||ar