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/
nikunj_ has quit [Ping timeout: 260 seconds]
nikunj has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
hkaiser has quit [Quit: bye]
parsa has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
nikunj has quit [Quit: Page closed]
Viraj has joined #ste||ar
Viraj has quit [Ping timeout: 260 seconds]
anushi has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
parsa has joined #ste||ar
parsa has quit [Read error: Connection reset by peer]
parsa| has joined #ste||ar
Anushi1998 has joined #ste||ar
parsa| has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
mcopik has quit [Ping timeout: 260 seconds]
<jbjnr>
heller: yt? Not expecting an answer on sunday morning, but ...
<jbjnr>
I want to create a user for pycicle, so that it can push status settings without my face/account. is there a special type of user on github that I can create that isn't like a normal user?
<jbjnr>
i.e. doesn't have any repos etc. just does status setting and that kind of thing
<heller>
jbjnr: there are special app accounts, IIRC
<heller>
jbjnr: my internet connection here is more than sloppy though ... so hard to check
Anushi1998 has joined #ste||ar
Anushi1998 has quit [Quit: Leaving]
<jbjnr>
heller: ok. I found those, but you need to create a developer thingy and do lots of stuff, so instead i've just created a 'pycicle' user account and will use that if someone adds it to stellar group so it can make changes etc.
<heller>
ok
<heller>
jbjnr: will do
<github>
[hpx] sithhell force-pushed docker_image from a733503 to aa9302b: https://git.io/vxFvP
<github>
hpx/docker_image aa9302b Thomas Heller: Fixing Docker image creation...
<hkaiser>
K-ballo: I have a question wrt future unwrapping
<hkaiser>
K-ballo: the test future_unwrap_878 ensures that if the outer future holding an exception is unwrapped, the exception ends up being in the inner one
<hkaiser>
do I misunderstand?
<K-ballo>
looking..
<github>
[hpx] sithhell force-pushed docker_image from 8bf3ca7 to 00d0767: https://git.io/vxFvP
<github>
hpx/docker_image 00d0767 Thomas Heller: Fixing Docker image creation...
<hkaiser>
jaafar: looks nice, say hello to her - good job
<hkaiser>
jbjnr: ^^
<jaafar>
There I go again :)
<jaafar>
Got to resume my HPX experiments again soon
<hkaiser>
jaafar: hey - sorry for poking you
<jaafar>
haha no, it's my fault for lurking!
<jaafar>
hkaiser: will I see you in Aspen?
<hkaiser>
jaafar: no, I won't be able to come (I originally wanted to give a talk but I missed the call for papers :/ )
<jaafar>
I'm sorry not to see you!
<hkaiser>
jaafar: we might meet at cppcon in Sep
parsa| has quit [Quit: Zzzzzzzzzzzz]
Anushi1998 has quit [Remote host closed the connection]
<github>
[hpx] hkaiser force-pushed ready_future_unwrap from b773c62 to 424daa3: https://git.io/vpeug
<github>
hpx/ready_future_unwrap 424daa3 Hartmut Kaiser: Do not unwrap ready future...
Anushi1998 has joined #ste||ar
<jbjnr>
hkaiser: I am going to submit a talk to cppcon this year hopefully.
diehlpk has joined #ste||ar
<hkaiser>
jbjnr: nice
<mbremer>
@hkaiser: yt?
<hkaiser>
mbremer: here
<mbremer>
Ahh, I had some question. I wanted to bug you about.
<hkaiser>
sure
<mbremer>
The first was with components, and register_as and connect_to.
<mbremer>
Presumably these are how components are registered in the agas. I was curious if there were any pitfalls with connect_to.
<mbremer>
It's a void function, so I was curious what happens if the object hasn't been registered in AGAS yet?
<hkaiser>
it will wait
<hkaiser>
the future returned by connect_co will become ready only once the object has been registered
<hkaiser>
well, or the client object will become valid only after the object was registered
<mbremer>
Yeah, I guess that was what I was worried about. If the client isn't valid yet, and I call an action with it. Presumably that will cause the code to crash?
<mbremer>
I.e. do i need to be careful that all of my clients are valid before I start calling invoking actions through them?
<hkaiser>
no, it will delay the action invocation until the client becomes ready
<hkaiser>
it might block however, iirc
<hkaiser>
we should change it such that it doesn't block...
<hkaiser>
need to look
<mbremer>
What would it do instead? Just have the action return after the client is ready?
<hkaiser>
yes
<hkaiser>
the action invocation accesses the id stored in the client, which will become available only once the client has become ready
<mbremer>
That sounds like the best thing I could think of.
<hkaiser>
mbremer: well, it could return without blocking, even if the id is not available
<mbremer>
I guess, I wonder it could then be nice to have connect_to be a future, that returns once the id is available.
<hkaiser>
it does that internally...
<mbremer>
Oh, hmm. I thought it was returned void atm.
<hkaiser>
the first one assumes that the clinet is ready, so it is called from elsewhere
<hkaiser>
yah, the first is called as the continuation for the second one
<mbremer>
I see so the future will be ready anyway
<hkaiser>
yes
<mbremer>
My second question, has to do with how HPX interplays with the c++11 memory model.
<mbremer>
I was thinking of writing a type of double buffer to replace the channels.
<hkaiser>
yah, our channels could be more efficient :/
<mbremer>
I was thinking that we could use constraints applied by the task graph to simplify the implementation. Basically only two messages can ever be in flight between two stencil tiles
<hkaiser>
ok
<hkaiser>
channel has an implementation allowing for one result in flight
<mbremer>
Well what I was curious about was if I could skip the mutexes.
<hkaiser>
currently we have local channels and remote ones
<hkaiser>
the remote channel always uses the unlimited_buffered_channel implementation
<mbremer>
Since the stencil calls get synchronized anyway with a when_all call.
<hkaiser>
k
<mbremer>
Is that enough synchronization to guarantee no race conditions occuring?
<hkaiser>
sounds like a possible optimization, a fixed-size-buffer channel
<hkaiser>
shrug, I don't know
<mbremer>
Yeah, but I think you definitely need a bidirectional stencil.
<hkaiser>
ok
<mbremer>
So like roughly, if you have two components, it roughly relies on the fact that for the i-th timestep, i+2th message couldn't be sent till the ith message has been processed
<hkaiser>
sounds correct to me
<mbremer>
And so with two buffers, and if you get sufficient thread synchronization in the when_all, you could guarantee with two buffers that threads would only exclusively be writing or reading from the vector at the recipient
<hkaiser>
mbremer: you could easily protect your internal buffer with a HPX mutex
<hkaiser>
that shouldn't be too much of an overhead
<hkaiser>
but not using a map<> to store the messages is definitely beneficial
<mbremer>
kk, I guess that is the answer to the more important question
<hkaiser>
you tell it at constructon time now many slots it has
<mbremer>
This is exactly what I was thinking of
<hkaiser>
Go allows to specify the length of the pipeline for channels
<hkaiser>
I was too lazy to implement that ;)
<hkaiser>
but here is you chance to become famous ;-)
Anushi1998 has quit [Ping timeout: 245 seconds]
parsa has joined #ste||ar
<mbremer>
I would be interested in trying to implement that
<hkaiser>
by all means
<hkaiser>
mbremer: easy enough to add a constructor parameter to lcos::channel allowing to specify the used buffer length (defaulting to -1 or somesuch)
<hkaiser>
then use different specializations of the local channel to implement it
<hkaiser>
-1 -> unlimited, 1: one_element_channel, else: your new stuff
<mbremer>
Yes, I see.
<mbremer>
I'm looking at the local channel now
<mbremer>
hkaiser: kk, let me think on it some. I really like this circular buffer data structure.
<mbremer>
But thanks for all of your insight. That helps a lot (and makes me sleep better at night ;) )
<ct-clmsn>
@hkaiser, where's a good place to start reading about the policies that ya'll implemented in executors?
<hkaiser>
:D
<hkaiser>
ct-clmsn : the code ;-)
<ct-clmsn>
(for like numa domain allocations, etc)
<ct-clmsn>
doah!
<ct-clmsn>
lol
<ct-clmsn>
fair enough!
<hkaiser>
no docs yet, sorry
<ct-clmsn>
it's cool
<ct-clmsn>
was hoping for a little bit more of a general orientation (directory) to be sure my intuition isn't too far off
<hkaiser>
ct-clmsn: we know it's too much in flux to spent time to document things
<ct-clmsn>
rgr
<hkaiser>
ct-clmsn: well, I can point you to the directories