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/
ct-clmsn has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
EverYoung has quit [Ping timeout: 246 seconds]
ct-clmsn has left #ste||ar ["Leaving"]
gedaj_ has quit [Read error: Connection reset by peer]
gedaj has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
<wash>
heller: we'll need a call to discuss the paper
<msimberg>
heller: I worded that badly, I was wondering if you'd already tried ubsan and found it useful (I had not yesterday)
gedaj has quit [Remote host closed the connection]
gedaj has joined #ste||ar
gedaj has quit [Remote host closed the connection]
gedaj has joined #ste||ar
david_pfander has joined #ste||ar
gedaj has quit [Remote host closed the connection]
gedaj has joined #ste||ar
<heller>
msimberg: nope, working pretty well
* jbjnr
is back in the office
<msimberg>
jbjnr: welcome back
<jbjnr>
23
<jbjnr>
ive ten points to anyone who can tell me what the 23 is for :)
<jbjnr>
^I will give ten ...
<heller>
jbjnr: welcome back
parsa[w] has quit [Read error: Connection reset by peer]
parsa[w] has joined #ste||ar
parsa[w] has quit [Read error: Connection reset by peer]
<msimberg>
___itt_domain doesn't need to be freed, it's the domain itself that needs to be freed
<msimberg>
(I think)
<msimberg>
but that said, what does HPX_NON_COPYABLE do?
<msimberg>
jbjnr
<jbjnr>
thr non copyable part just makes sure that someone else doesn't hold on to the underlying things inside it.
<jbjnr>
the NON_COPYABLE macro just hides all the copy/move constructors
<jbjnr>
hk is fastidious about safety of these classes if they hold onto internal pointer that might be accessed from outside the class
<msimberg>
hmm, thanks
<jbjnr>
if the problem is that the domain is not being freed, then hk has misunderstood, but his comment is still valid. Free the itt_ thingy in the destructoy, make sure the destrovctor is called (you fix), and make it non copyable so nobody else can hold it when it is freed
<jbjnr>
^soffy my typing bad
<jbjnr>
^sorry
<jbjnr>
shite
<msimberg>
:)
<msimberg>
I think that helps, thanks
<msimberg>
maybe it's just the instead in hkaiser's wording that's confusing me...
<msimberg>
I'll check with him later
<jbjnr>
he's saying, make sure the itt_ thingy is freed when the domain is freed. but maybe he doesn't realize that the domain isn't being freed so you added an itt_ free or whatever ....
<jbjnr>
that's then execute - I think it must be wrong
<hkaiser>
jbjnr: is that your then-execute or the one emulating its functionality?
<jbjnr>
that's the real one
<hkaiser>
real == yours?
<jbjnr>
yes mine
<hkaiser>
it's the same as the emulating one
<jbjnr>
the creation of the continunation exec is calling async_execute
<jbjnr>
aha. so I did cut'n'paste wrong
<jbjnr>
good.
<hkaiser>
sure it does, do you really need it?
<jbjnr>
no. I just want to execute and return a future
<hkaiser>
just call dataflow with the predessesor and all of your arguments
<jbjnr>
the final line commented out. can I just wrap that in a future
<hkaiser>
jbjnr: 'F' is yur function, right?
<jbjnr>
yes. essentially
<hkaiser>
why not just do a dataflow(F, predecessor, forward<Ts>(ts)...) ?
<hkaiser>
or wrap F into something of your own to handle all the arguments
<jbjnr>
ok. thanks
<hkaiser>
jbjnr: you have essentially reproduced the emulation of then_execute
<jbjnr>
got it.
<jbjnr>
I knew it must be wrong, but I was too scared to try it my own way without asking first.
<hkaiser>
then_execute should execute the given function F after th epredecessor has become ready, that all - however you manage to do that...
<msimberg>
hkaiser: could I also ask for some clarification on the pr I opened?
<hkaiser>
absolutely
<msimberg>
hkaiser: so do you mean that I should be freeing the ___itt_domain in the domain destructor *in addition* to the reset function that I added? or would that somehow replace what I added?
<hkaiser>
no, instead of
<msimberg>
because the problem that I saw was that the domain was not freed
<hkaiser>
the domain instance goes out of scope at the end of the scheduling loop, so calling your reset function from the omain destructor would be a good thing (tm)
<hkaiser>
msimberg: yes, you found a problem, all I suggest is to solve it differently from what you proposed
<msimberg>
hkaiser: I really appreciate the feedback, I'm just at a level where I don't quite understand how your solution works
<msimberg>
I feel like I'm missing something very basic, but the problem is that the domain destructor does not get called at the end of scheduling_loop
<jbjnr>
(go ahead and fix it by making sure it does get destroyed)
<msimberg>
jbjnr: right, I'm thinking too small...
<zao>
« #VisualStudio tip: /Gw compiler option puts each data symbol in its own section -> more linker stripping -> smaller EXE. #cpp »
<zao>
Not that we have that many, I reckon.
<hkaiser>
msimberg: I'm 100% sure the domain destructor will be called whenever the object goes out of scope
<hkaiser>
yah, barely worth the effort ;)
<hkaiser>
I think however that we already use this flag
<hkaiser>
msimberg: if it wasn't called the compiler was broken
hkaiser has quit [Quit: bye]
gedaj has quit [Remote host closed the connection]
gedaj has joined #ste||ar
<jbjnr>
hkwhen then_execute is called, the predecessor future should be ready already yes? (and the Args &&args... are nonsense because there are none anyway - since .then only passes the previous future through)
<jbjnr>
aha. he'sleft
<K-ballo>
no, not ready
<K-ballo>
not necessarily
<jbjnr>
surely it will only be called when the prefious future trigggers it?
<K-ballo>
no, exec.then_execute gets called when you do future.then(...)
hkaiser has joined #ste||ar
<K-ballo>
*when you do future.then(exec, ...)
<K-ballo>
let me check..
<jbjnr>
bu the continuation isn't callen then
aserio has joined #ste||ar
<jbjnr>
hkaiser: you're back
hkaiser has quit [Read error: Connection reset by peer]
<jbjnr>
perhaps not
<K-ballo>
yep, it's called form within future::then(Executor
<jbjnr>
does that mean it's ready or not?
hkaiser has joined #ste||ar
<K-ballo>
not necessarily, it's the `f` from `f.then(exec, ...)`
<K-ballo>
you are asking to implement .then for your executor after all
<jbjnr>
I wanted to simplifty things by not using dataflow because if the future was always ready when then_execute is entered ...
<jbjnr>
dataflow is giveng me too many errors ....
<K-ballo>
what's the ultimate goal here?
<jbjnr>
to implement then_Execute
<K-ballo>
no, I mean, the ulterior? one? the end goal?
<K-ballo>
what do you want to implement then_execute for
<jbjnr>
when tasks are scheduled, I am executing an extra function beforehand that generates a hint for the scheduler to tell it which numa domain or core to use.
<jbjnr>
so I must intercept the tasks before they reach the scheduler
<jbjnr>
hence the custom executor
<jbjnr>
the numa function is a kind of lambda that is task specific
<jbjnr>
so the executor is templated on a lambda (or function) that "does the right thing" (TM)
<K-ballo>
makes sense, but then_execute intercepts tasks at the point of creation not the point of execution
<jbjnr>
ok, but in async_execute, I delay the tasks with dataflow - and then get the args etc to call the numa hint.
<jbjnr>
I'd like to do the same in then_execute
<jbjnr>
so I'd better keep the dataflow :(
<K-ballo>
async_execute also gets called at the point of creation, not execution
<K-ballo>
which I guess it's the same :P
<jbjnr>
by delay the tasks, I mean - dataflow only passes them on once they become ready, so then I can get the correct vars out of them and invoke the numa hint
<jbjnr>
it works for async_Execute and my scheduler (lso custom), gets the hints
<jbjnr>
but most of our linear algebra is continuations on matrix blocks once another block is done
eschnett has quit [Quit: eschnett]
<K-ballo>
I don't follow, the tasks in async_execute are ready on construction
<jbjnr>
yes, but some args might be futures
<K-ballo>
ah, but you are not supposed to wait on those, I see
<K-ballo>
that's what you mean by "delay" then
<jbjnr>
actually, I will never have future args in practice I don't think
<jbjnr>
yes. delay. = not wait, but unwrap once ready
<jbjnr>
needs to work for then though
<K-ballo>
both async_execute and then_execute ask for a task to be scheduled, but only then_execute has a dependency that must get ready
<jbjnr>
corrrect. my isunderstanding here was that then_execute would only be called once the predecessor was already ready
<jbjnr>
so I'll scratch my plan to remove the dataflow
<K-ballo>
the fallback implementation does that, schedules a call to async_execute once the predecessor was already ready
hkaiser has quit [Read error: Connection reset by peer]
<K-ballo>
but the wrapping fools you and stops you from getting the magic arguments
<K-ballo>
I see
<jbjnr>
I'm very close to a solution now I think. Just a bit more time :)
<K-ballo>
it wouldn't be unreasonable for the fallback to do unwrapping before calling the executor
<jbjnr>
well this executor does basically that. it unwraps, calls the hint function, then forwards to a treal executor held as an internal var
<jbjnr>
(sort of)
aserio has quit [Read error: Connection reset by peer]
aserio has joined #ste||ar
hkaiser has joined #ste||ar
<hkaiser>
heller, jbnr: planning to join
<hkaiser>
?
<jbjnr>
hkaiser: join what?
<jbjnr>
Operation bell? Not me. Not involved any more
eschnett has joined #ste||ar
<hkaiser>
jbjnr: we wee talking about what to do with the paper
<jbjnr>
decision?
<hkaiser>
you were not there, so what could we do?
<jbjnr>
lol
<jbjnr>
you do not need me
<hkaiser>
do you want for the paper to be published?
<jbjnr>
wash and heller have to decide. they did most of the work
<hkaiser>
they were not on the call either
<jbjnr>
I am working on a new paper anyway.
<hkaiser>
who needs to publish existing papers if you can work on a new one - heh
<jbjnr>
this was not "my" paper though
<jbjnr>
I helped where I could but no more.
<jbjnr>
these consts are doing my in
<jbjnr>
doing me in - I should say
<wash[m]>
hkaiser: sorry, I just saw the email. Can you subscribe me to the list again with brycelelbach@gmail.com?
<wash[m]>
Hkaiser: the comments on the paper were positivie. It's just that we were off topic
<wash[m]>
We can submit to SC maybe for next year, or something
<wash[m]>
I need to sleep now though, I was at work all night
<hkaiser>
wash[m]: we discussed submitting to a journal Alice is an editor for
<hkaiser>
wash[m]: you should have seen her email
<wash[m]>
I'd suggest ISC or journal. Let me check out the journal Alice suggested
<jbjnr>
ISC = No. it's utter shite and you should never submit anything there.
<hkaiser>
wash[m]: we talked about submitting before sc to the journal, Alice promised to get us feedback before the isc deadline
<wash[m]>
K
<wash[m]>
It's a pity about IPDPS. But we knew the deadlines were like this
<hkaiser>
jaafar: didn't you say it;s not your paper and that you don't care?
<hkaiser>
jbjnr: ^^
* jbjnr
goes silent
<hkaiser>
wash[m]: when was the deadline for ipdps?
<hkaiser>
(i.e. we might still be able to sneak in)
<jbjnr>
no. IPDPD is very high standard. no sneaking
<jbjnr>
IPDPS^
<wash[m]>
It was Oct 22nd
<hkaiser>
darn
<wash[m]>
See private
<jbjnr>
PS. hkaiser the new paper I'm working on. You are one of the authors! :)
<jbjnr>
susprise!
<hkaiser>
YAY
pree has joined #ste||ar
RostamLog has joined #ste||ar
<github>
[hpx] hkaiser created client_base_registration (+1 new commit): https://git.io/vFJoI
<github>
hpx/client_base_registration 76864c2 Hartmut Kaiser: Making sure client_base instance that registered the component does not unregister it when being destructed
<msimberg>
so my next question is: get_thread_itt_domain is called in multiple places and I don't want to reset anything as long there might be other references to it
<msimberg>
is it okay if I try to wrap it in something like a shared_ptr? do you think that would even work?
<github>
[hpx] hkaiser opened pull request #2976: Making sure client_base instance that registered the component does not unregister it when being destructed (master...client_base_registration) https://git.io/vFJon
<hkaiser>
msimberg: nah, I don't think we should go that far
<hkaiser>
msimberg: that's why I suggested to make domain() explicitly non-copyable and add the appropriate support to the class preventing us from misusing it
aserio has quit [Ping timeout: 255 seconds]
<jbjnr>
OMFG - K-ballo I have a working then_execute that actualy works!
<K-ballo>
lol
<hkaiser>
jbjnr: looks like it's wrong anyways - then_execute_helper will modify the future (by attaching a continuation), so I guess you'd do a good deed ;)
<K-ballo>
those consts are odd, but I believe I was the one that put them there
<jbjnr>
hkaiser: correct. a continuation on a future taking a const future. seems unliklely
<hkaiser>
jaafar: a working one which actually works! that's success
<jbjnr>
K-ballo: I fogive you.
<hkaiser>
jbjnr: ^^
<jbjnr>
that's forgive in the usual English
<hkaiser>
K-ballo: pls send your itinery for pick-up services to be scheduled
jaafar has quit [Remote host closed the connection]
<msimberg2>
K-ballo: thanks
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
<github>
[hpx] hkaiser force-pushed client_base_registration from 76864c2 to 5741e55: https://git.io/vFJ7a
<github>
hpx/client_base_registration 5741e55 Hartmut Kaiser: Making sure client_base instance that registered the component does not unregister it when being destructed