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/ | GSoC2018: https://wp.me/p4pxJf-k1
anushi has joined #ste||ar
hkaiser has quit [Quit: bye]
anushi has quit [Remote host closed the connection]
anushi has joined #ste||ar
anushi has quit [Ping timeout: 248 seconds]
anushi has joined #ste||ar
anushi has quit [Remote host closed the connection]
anushi has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
anushi has quit [Ping timeout: 240 seconds]
nanashi64 has joined #ste||ar
nanashi55 has quit [Ping timeout: 256 seconds]
nanashi64 is now known as nanashi55
anushi has joined #ste||ar
anushi has quit [Ping timeout: 265 seconds]
anushi has joined #ste||ar
anushi has quit [Ping timeout: 276 seconds]
nanashi64 has joined #ste||ar
nanashi55 has quit [Ping timeout: 245 seconds]
nanashi64 is now known as nanashi55
anushi has joined #ste||ar
anushi has quit [Remote host closed the connection]
anushi has joined #ste||ar
anushi has quit [Ping timeout: 256 seconds]
anushi has joined #ste||ar
anushi has quit [Remote host closed the connection]
anushi has joined #ste||ar
anushi has quit [Ping timeout: 265 seconds]
anushi has joined #ste||ar
jaafar_ has quit [Ping timeout: 260 seconds]
david_pfander has joined #ste||ar
anushi has quit [Read error: Connection reset by peer]
anushi has joined #ste||ar
anushi has quit [Read error: Connection reset by peer]
zura has joined #ste||ar
<jbjnr>
heller: yt?
<heller>
jbjnr: hey!
<jbjnr>
I just forwarded question from hmed
<jbjnr>
^Ahmed
<jbjnr>
I am puzzzled by our use of fi_context
<jbjnr>
(or non use). if the provider requires FI_CONTEXT, then shouldn't we have one inside our receiver/sender structs
<heller>
me too :P
<heller>
we don't use it
<heller>
yes, we just passs in the sender/receiver object
<heller>
fi_context is just the size of a pointer anyways
<jbjnr>
what if LF overwrites something in there
<jbjnr>
(PS. I am on holiday in south of France at the moment. - hence lack of presence on IRC)
nikunj has quit [Remote host closed the connection]
nikunj97 has joined #ste||ar
<heller>
jbjnr: yes
<jbjnr>
I'll add one as the first member of the sender and receiver structs, then hopefully the pointer to the sender/receiver should point to the fi_context and everyone is happy
zura_ has joined #ste||ar
zura has quit [Ping timeout: 248 seconds]
zura_ has quit [Read error: Connection reset by peer]
zura_ has joined #ste||ar
<jbjnr>
annoying, with gni provided fi_context is not required, that's probably why we had no problems. We use an rma_base for the sender and rma_receiver types and it has virtual members which breaks a simple inclusion of fi_context to guarantee that the first bytes point to a fi_context object
<jbjnr>
all th other providers require fi_context, so we'd better support it properly
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
nikunj1997 has joined #ste||ar
nikunj97 has quit [Ping timeout: 248 seconds]
nikunj1997 has quit [Remote host closed the connection]
nikunj1997 has joined #ste||ar
<heller>
jbjnr: no, it's a non issue... the LF PP is working fine over TCP
<heller>
jbjnr: the only thing you need to do is to make sure that there's enough space in the object pointed to for the context, at least as far as I understand...
eschnett has joined #ste||ar
eschnett has quit [Quit: eschnett]
aserio has joined #ste||ar
hkaiser has quit [Quit: bye]
zura_ has quit [Ping timeout: 260 seconds]
akheir has joined #ste||ar
eschnett has joined #ste||ar
zura_ has joined #ste||ar
zura_ has quit [Ping timeout: 256 seconds]
diehlpk has joined #ste||ar
hkaiser has joined #ste||ar
zura_ has joined #ste||ar
<mbremer>
@hkaiser: To follow-up from the weekend. Is it necessary that the component be loaded, and then moved? In that case my move ctor would be quite expensive.
<mbremer>
Alternatively, if I could pass a continuation that will set all the pointers/references once the component has been constructed on the new locality that would work as well. If that's easier, I wouldn't mind that either.
rtohid_ has joined #ste||ar
rtohid has left #ste||ar ["Leaving"]
rtohid_ has left #ste||ar [#ste||ar]
rtohid_ has joined #ste||ar
diehlpk_mobile has joined #ste||ar
<hkaiser>
mbremer: isn't the component directly desialized into the new spot?
<hkaiser>
deserialized*
<mbremer>
So when I run something like the migrate component test
<mbremer>
it calls load and then a move constructor
<hkaiser>
right...
<mbremer>
Is it possible to avoid this move?
<hkaiser>
why is your move-constructor expensive?
<hkaiser>
it's the way it's implemented, currently - don't think we can change that easily
<mbremer>
It's a graph like structure. My edges currently have pointers to the vertices, which are stored in a container that doesn't allow random accesses
<hkaiser>
but there is a callback on the component that is called once the migration is done
<mbremer>
So in the move, I'd have to reset the pointers. Maybe, I can just do that in the call-back?