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/
<hkaiser>
K-ballo: the async traversal stuff broken gcc 4.9
<K-ballo>
all the deduced and faux deduced return types are killing me
<K-ballo>
I don't remember whether that use case ended up being valid or not
<hkaiser>
nod
<K-ballo>
change visitor() in decltype by declval<Visitor const&> or whatever is appropriate
<hkaiser>
would it make sense for me to invest the time and to make the return type calculations explicit?
<K-ballo>
definitively
<K-ballo>
I was about to say that return type sucks
<K-ballo>
there should be some higher level notion of what the return type is
<hkaiser>
yes
<hkaiser>
it's difficult to follow as it is
<K-ballo>
as is everything happens to return whatever it happens to return (assuming no copy/paste errors)
<hkaiser>
lol yah
<hkaiser>
ok, will carve out some time for this
<K-ballo>
I'm currently breaking them all in a branch to get some decent diagnostics out
<hkaiser>
K-ballo: just wanted to make sure that I don't create any unneeded conflicts for you if I do
<hkaiser>
ahh, then I'll better wait for you
<hkaiser>
let's talk about this f2f
<K-ballo>
I'm not planning to commiting any of that
<hkaiser>
ok
<hkaiser>
might be a useful intermediate state anyways
<K-ballo>
don't hold the gcc fix though
<hkaiser>
sure
<hkaiser>
that one should be easy enough
<hkaiser>
famos last words
rod_t has left #ste||ar [#ste||ar]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
<github>
[hpx] hkaiser created fixing_async_traversal_gcc49 (+1 new commit): https://git.io/vdyXb
<github>
hpx/fixing_async_traversal_gcc49 d2ce06b Hartmut Kaiser: Attempt to fix the gcc 4.9 problem with the async pack traversal
<github>
[hpx] hkaiser opened pull request #2961: Attempt to fix the gcc 4.9 problem with the async pack traversal (master...fixing_async_traversal_gcc49) https://git.io/vdyXA
EverYoung has quit [Ping timeout: 252 seconds]
eschnett has joined #ste||ar
gedaj_ has joined #ste||ar
gedaj_ has quit [Client Quit]
gedaj has quit [Ping timeout: 240 seconds]
hkaiser has quit [Quit: bye]
gedaj has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
wash has quit [Quit: leaving]
jaafar has joined #ste||ar
pree has joined #ste||ar
pree has quit [Read error: Connection reset by peer]
pree has joined #ste||ar
<github>
[hpx] sithhell force-pushed fix_thread_map from 36544eb to 10d0dd1: https://git.io/vdy5W
<github>
hpx/fix_thread_map 10d0dd1 Thomas Heller: Partially reverting background thread handling during shutdown...
jaafar has quit [Ping timeout: 252 seconds]
eschnett has quit [Quit: eschnett]
<msimberg>
hkaiser: morning here now, I'm also on swiss time
<msimberg>
a call would definitely be useful, and I'm free nearly any time during working hours
<msimberg>
nothing concrete has been planned yet though, except in my head and most probably jbjnr's head
pree has quit [Quit: AaBbCc]
david_pfander has joined #ste||ar
<github>
[hpx] sithhell created revert_throttle_changes (+1 new commit): https://git.io/vdSL1
<github>
hpx/revert_throttle_changes 13c3f67 Thomas Heller: Partially reverting #2891...
<hkaiser>
heller: could you explain what you're changing in the scheduling, pls?
<hkaiser>
difficult to follow from the diffs
<heller>
hkaiser: yeah, essentially rolling back to the state before #2891
<hkaiser>
good
<heller>
as the commit message is saying ;)
<hkaiser>
well, it says 'partially'
<heller>
yes, partially since some changes are still valid
<hkaiser>
and I asked you to explain what you're changing ;)
<heller>
which boils down to the code in the scheduling policies checking if a core is in use or not
<heller>
in order to dynamically remove PUs, I had to mess with the termination detection and wait_or_add_new, which led to the hangs
<heller>
where wait_or_add_new was part of the termination detection
<heller>
so i rolled back the changed to wait_or_add_new and removed the special handling for the background thread which seemed to be buggy
<hkaiser>
ok
<github>
[hpx] hkaiser force-pushed fixing_2947 from a5d12ef to e6b1549: https://git.io/vdSGL
<github>
hpx/fixing_2947 e6b1549 Hartmut Kaiser: Making sure any hpx.os_threads=N supplied through a --hpx::config file is taken into account...
<github>
[hpx] hkaiser closed pull request #2950: Fix a namespace compilation error when some schedulers are disabled (master...namespace_error) https://git.io/vdMAw
<hkaiser>
msimberg: jbjnr mentioned that you're working on dynamic footprints for schedulers
<hkaiser>
I have to implement related functionalities soon - may I ask you to schedule a skype call or somesuch in the near future to talk about this?
<hkaiser>
trying to avoid duplication of work
<msimberg>
yeah, first steps would be suspending/resuming the whole runtime as opposed to reinitializing everything each time, and this would eventually go towards controlling individual pools as well
<hkaiser>
msimberg: ok, have you started to work on this?
<msimberg>
no, so far only reading code, so very early stages
<hkaiser>
could we talk before you do?
<msimberg>
so your input would be very helpful before I do anything
<msimberg>
yes, definitely
<hkaiser>
msimberg: jbjnr wanted to join as well
<hkaiser>
would next week be a go target?
<msimberg>
yeah, saw that, he's supposed to travel sometime today, but may be available later in the week as well
<msimberg>
ok for me, jbjnr is on holiday next week
<msimberg>
as I said before my schedule is pretty flexible so it may be easiest if you let me know with a short warning when you would have time
<hkaiser>
ahh, then let's wait for him to be back
<msimberg>
we could probably manage without him, but it would probably be nice to have him there as well, he knows a lot about the background as well
<msimberg>
let's see what he says
<hkaiser>
ok, fine by me - pls coordinate with him
<msimberg>
ok, you're generally available the next few weeks?
<hkaiser>
yes, next travel is in November only
<msimberg>
good
<hkaiser>
msimberg: pls be proactive about communication here
<msimberg>
hkaiser: sure
<hkaiser>
:D
<msimberg>
hmm, I feel like I
<msimberg>
'm missing something :/
<hkaiser>
heller: can we merge your patch now? I really would like to make buildbot more reliable again
<msimberg>
hkaiser: the default number of threads is set correctly now with 2947, but implicitly loading from a file still doesn't work
<msimberg>
it should work without any command line options, right? or does it need some special syntax?
<msimberg>
the reason I'm trying this out btw is for when you might have some hpxified library to which you might not be able to or want to pass argv and argc
K-ballo has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
<hkaiser>
heller: yah saw that one - working on it
jaafar_ has quit [Ping timeout: 252 seconds]
<heller>
hkaiser: thanks!
<msimberg>
hkaiser and everyone actually: do you generally read the backlogs from when you're offline? (I just realized I replied to you in the morning when you were away...)
<hkaiser>
msimberg: sometimes I do read it, not always
<hkaiser>
heller: this is caused by Denis removing the future invalidation from dataflow, I'll follow up with him on this
<msimberg>
okay, thanks, I'll stick to when you're online in that case
<hkaiser>
tks
<heller>
hkaiser: ahh, I see
<hkaiser>
do you remember why he did this?
<heller>
he found it to be odd
<heller>
and thought the frames would be released anyways
<heller>
no
<heller>
the frames should be released once the dataflow shared state goes out of scope
<heller>
one sec
<hkaiser>
heller: I agree
<heller>
he moves the shared states around now instead of explicitly invalidating them
<hkaiser>
they don't get released at all now
<hkaiser>
hold on
<hkaiser>
no, it's the (callback) function which is not being released
<heller>
should be a unique_function, right? which is released once it is called, no?
<hkaiser>
who releases it?
<hkaiser>
a unique_function does not mean that it is being called once
<heller>
sure
<hkaiser>
the problem is that the future states could create a circular dependency with the dataflow shared state
<heller>
yes
<hkaiser>
we need to release them explicitly
<heller>
ok
<heller>
hkaiser: hmmm. I always was under the impression that a unique_function is supposed to be invoked once only
<heller>
to reflect use cases like deferred_call etc. where the arguments are moved out of the bound tuple
<hkaiser>
heller: that's call_once()
<hkaiser>
unique_function is a move-only function<>
<heller>
call_once is for static initialization, another totally different use case
<heller>
yes, it is a move only function
<hkaiser>
sorry, I meant util::one_shot
<heller>
yes, unique_function<...> f = util::one_shot(...); f(); // fine
<heller>
another f() should throw an error that the function is now empty
<hkaiser>
heller: but that's unrelated
<heller>
yes, it is
<hkaiser>
shrug
<hkaiser>
I take everything back, it's not the change Denis made
<hkaiser>
we have to release the dataflow function explicitly after all - no idea how this ever worked properly...
<github>
[hpx] hkaiser created fixing_dataflow (+1 new commit): https://git.io/vdSgO
<github>
hpx/fixing_dataflow 336effe Hartmut Kaiser: Making sure any function object passed to dataflow is released after being invoked...
<hkaiser>
heller: ^^
<github>
[hpx] hkaiser opened pull request #2963: Making sure any function object passed to dataflow is released after being invoked (master...fixing_dataflow) https://git.io/vdSgG
<hkaiser>
this could also explain the 'memory leaks' we saw with octotiger
<heller>
hmm
<heller>
could be
denisblank has joined #ste||ar
<denisblank>
hkaiser: I received your mail, are you here?
<hkaiser>
hey denisblank
<diehlpk_work>
heller, we skype today at 2pm/3pm/7pm about the paper.
<hkaiser>
all is well, it's not your change, it was a separate issue, see #2963
<heller>
diehlpk_work: ok. not sure I can attend. I am always never free at 7
<denisblank>
Ah perfect, because I checked that as I made the change and the future invalidation was needed because the pack was passed as l-value and never invalidated. Now we are passing it as r-value which also leads to correct destruction.
<hkaiser>
heller: always or never? ;)
<diehlpk_work>
heller, Ok, what time is better for you
<diehlpk_work>
We still can chnage it
<K-ballo>
denisblank: while you are here...
<K-ballo>
denisblank: which piece(s) of your implementation are the ones that could be sensible to all_of/any_of/none_of? I remember you asking about short-circuiting guarantees at one point in time
<denisblank>
As I remind the only used spot is the legacy implementation of unwrapped, because I replaced some recursive instantiations with linear ones after that
<heller>
hkaiser: always never, emphasizing the *never* part :P
<heller>
diehlpk_work: today isn't good for me
<diehlpk_work>
Ok, we have to start to do changes for the paper because deadline for camera ready is this Friday
<diehlpk_work>
heller, When do you have time this week such we have enough time to correct the paper?
<heller>
diehlpk_work: tomorrow is good for me
aserio has joined #ste||ar
<heller>
I am fine with following your orders
<heller>
and we don't have to change a lot
<aserio>
hkaiser: yt?
<hkaiser>
ashere
<hkaiser>
aserio here
<aserio>
hkaiser: see pm
<diehlpk_work>
hkaiser, zbyerly Would you have time for skype tomorrow as well?
<hkaiser>
diehlpk_work: yah, should work (except 10:30-11:30am CDT)
<zbyerly>
diehlpk_work, yes
<diehlpk_work>
heller, So please suggest a time for you tomorrow
<heller>
diehlpk_work: 8am or 9am
quaz0r has quit [Ping timeout: 248 seconds]
<aserio>
I have never appreciated how fast my internet connection is at work....
<heller>
lol
<zbyerly>
aserio, my internet connection here is currently infinity % faster than at home
<github>
[hpx] sithhell closed pull request #2961: Attempt to fix the gcc 4.9 problem with the async pack traversal (master...fixing_async_traversal_gcc49) https://git.io/vdyXA
<aserio>
zbyerly: how does Nexflix even work at my house
akheir has joined #ste||ar
<aserio>
hkaiser: did y'all have a pull request that you are about to merge?
<zbyerly>
aserio, are you guys both sick??
<aserio>
zbyerly: yep
<aserio>
but from the sound of it hkaiser is worse off
<zbyerly>
aserio, did you get the flu shot this season?
<aserio>
zbyerly: no, but I don't think this is the flu
quaz0r has joined #ste||ar
<aserio>
just a nasty cold
<zbyerly>
aserio, you want me to physically host the meeting tomorrow? like open the door, get the laptop, etc
<aserio>
zbyerly: If I don't make it in tomorrow that would be great :)
<aserio>
I do think I will be fine tomorrow though...
<github>
[hpx] K-ballo force-pushed pack-short-circuit from 3293416 to 0245afe: https://git.io/v762b
<hkaiser>
parsa[[w]]: talk to Rod to get that fixed, if needed
<parsa[[w]]>
hkaiser: there's another commit that's not showing up in the PR
<hkaiser>
ok, just push it to the branch
<parsa[[w]]>
i did push it to my fork's master that's in this PR but it's not showing up
parsa[[w]] is now known as parsa[w]
<zao>
parsa[w]: In general, it's encouraged when making a PR to do it from a branch on your side. That way, it can be rewritten and you avoid that future work affects PRs.
eschnett has joined #ste||ar
<zao>
(all commits from the branch sneak into the PR, even if completely unrelated work)
<hkaiser>
parsa[w]: also, you might want to do it from a github clone, not a separate repo github doesn't know that it is connected
<parsa[w]>
zao: understood, but all of that is reset and don't matter once a PR is closed
<zao>
Just saying, it's not wise to do even if it happens to go well.
<parsa[w]>
hkaiser: i wanted you to see the changes so i committed and created that repo on the fly
<parsa[w]>
zao: fair enough. got any ideas why the other changeset is not showing up?
<K-ballo>
I wonder if github is somehow protecting from unintended PR from master
<zao>
`This branch is 2 commits ahead of STEllAR-GROUP:master.`
<K-ballo>
nope, it's showing now.. just late
<zao>
Both those commits show in the PR, as far as I can tell.
<K-ballo>
"large queue backlog"
<K-ballo>
there was one missing about two minutes ago when I first looked
<aserio>
parsa[w]: Would you navigate to the post and see if you can view the YouTube link listed there?
<parsa[w]>
aserio: the link works
<parsa[w]>
all links on the page work: youtube video and the pdfs
<parsa[w]>
***pdf, and the txt
<parsa[w]>
files
<aserio>
parsa[w]: thanks for checking for me!
<parsa[w]>
you're most welcome
hkaiser has quit [Quit: bye]
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoun_ has joined #ste||ar
EverYoung has quit [Ping timeout: 252 seconds]
jfbastien has joined #ste||ar
<github>
[hpx] sithhell deleted fixing_dataflow at 336effe: https://git.io/vd9O7
<heller>
Alright, this should make is mostly good again
jaafar_ has joined #ste||ar
jaafar has quit [Ping timeout: 246 seconds]
jakemp has joined #ste||ar
<jaafar_>
Should a parallel execution of merge() be stable?
jaafar_ is now known as jaafar
<K-ballo>
the std:: one is required to be
<jaafar>
How about the hpx one :)
<K-ballo>
the hpx one strives to be conformant, so it better be stable
<jaafar>
I guess I should file a bug then!
<K-ballo>
oh shoot, I thought it was a philosophical question
<jaafar>
The test case is a little challenging. There is a 2^16 minimum threshold for using the parallel algorithm. I defeated it by setting the threshold to 10 for the purpose of debugging
<jaafar>
But if that's OK I will send what I have
<K-ballo>
taeguk[m]: you implemented parallel::merge, right?
<K-ballo>
jaafar: anything that reproduces the issue ought to help
<heller>
2^16 sounds like a rather high threshold
<jaafar>
OK #2964
<K-ballo>
jaafar: thanks!
<K-ballo>
I didn't know github issues took attachments
<jaafar>
Happy to help :)
<jaafar>
Maybe I did it the wrong way
<jaafar>
they won't take cpp attachments
Bibek has quit [Quit: Leaving]
Bibek has joined #ste||ar
<heller>
after a long lasting period of almost a month ... we are back with a fixed version