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
diehlpk has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
EverYoung has quit [Ping timeout: 265 seconds]
parsa has joined #ste||ar
EverYoung has joined #ste||ar
parsa has quit [Ping timeout: 240 seconds]
EverYoung has quit [Remote host closed the connection]
eschnett has joined #ste||ar
diehlpk has quit [Remote host closed the connection]
diehlpk has joined #ste||ar
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 276 seconds]
ABresting has joined #ste||ar
diehlpk has quit [Ping timeout: 240 seconds]
parsa has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
nanashi55 has quit [Ping timeout: 248 seconds]
nanashi55 has joined #ste||ar
Anushi1998 has quit [Ping timeout: 276 seconds]
Anushi1998 has joined #ste||ar
apsknight has quit [Ping timeout: 265 seconds]
Anushi1998 has quit [Ping timeout: 255 seconds]
ABresting has quit [Quit: Connection closed for inactivity]
Anushi1998 has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
apsknight has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
Anushi1998 has quit [Ping timeout: 265 seconds]
gedaj has quit [Read error: Connection reset by peer]
_gedaj_ has joined #ste||ar
hkaiser has quit [Ping timeout: 255 seconds]
_gedaj_ has quit [Remote host closed the connection]
_gedaj_ has joined #ste||ar
<heller>
zao: so you would say singularity is docker done right?
_gedaj_ has quit [Read error: Connection reset by peer]
gedaj has joined #ste||ar
Anushi1998 has joined #ste||ar
<zao>
A bit different niches, I’d say. Singularity is more about dipping into an image with most of the host mapped in (networking, home dir, devices, etc.) to run something in a somewhat different way.
<zao>
While Docker and LXC is more about persistent lightweight VM-like envs, with NAT-by-default and whatnot.
<zao>
It is definitely a project that is needed out there, let’s just hope they learn how to responsibly write suid binaries and handle incidents.
<zao>
Because holy heck, they did approximately everything wrong handling my vulnerability :D
<heller>
;)
simbergm has joined #ste||ar
ABresting has joined #ste||ar
jaafar has quit [Ping timeout: 264 seconds]
apsknight has quit [Read error: Connection reset by peer]
gedaj has quit [Remote host closed the connection]
<zao>
Bah, vectorization talk is all OpenMP hogwash.
<zao>
(got Intel people here running a KNL workshop)
EverYoung has quit [Ping timeout: 255 seconds]
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
K-ballo has joined #ste||ar
anushi has quit [Read error: Connection reset by peer]
anushi has joined #ste||ar
<hkaiser>
zao: forget this, KNL has been declared to be dead by Intel itself
<hkaiser>
also omp does not scale on knl
<zao>
Hehe.
<heller>
noone does :P
<zao>
This is PRACE, maybe they're slow on the uptake :P
<hkaiser>
heller: some do better than others ;)
<heller>
the machines that have been provisioned are better being used
<zao>
Also, we have actual KNLs in production, so helps to teach our users to get some use out of them.
anushi has quit [Quit: bye]
parsa has joined #ste||ar
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 276 seconds]
nanashi55 has quit [Ping timeout: 255 seconds]
nanashi55 has joined #ste||ar
nikunj has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
parsa has quit [Quit: Zzzzzzzzzzzz]
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 255 seconds]
nikunj has quit [Ping timeout: 264 seconds]
nikunj has joined #ste||ar
aserio has joined #ste||ar
eschnett has quit [Quit: eschnett]
eschnett has joined #ste||ar
hkaiser has joined #ste||ar
<zao>
Have you fine people had anything to do with Mikko Byckling and Asma Farjallah from Intel?
zao has quit []
zao has joined #ste||ar
anushi has joined #ste||ar
anushi has quit [Client Quit]
Anushi1998 is now known as anushi
Anushi1998 has joined #ste||ar
<hkaiser>
heller: is the make_ready_future PR ok with you now?
diehlpk has joined #ste||ar
parsa has joined #ste||ar
nanashi55 has quit [Ping timeout: 255 seconds]
nanashi55 has joined #ste||ar
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
nikunj has quit [Ping timeout: 264 seconds]
nikunj has joined #ste||ar
khuck has joined #ste||ar
<khuck>
@hkaiser - you there? I think I found a problem with the parent_id stuff in HPX. I am getting an hpx_init_data with a parent_id pointer, but its data is garbage.
<khuck>
I am wondering if I can just check the parent_id.thrd_->current_state_.state_ value - it is 0
<khuck>
but other members, like the parent_thread_id_ and the parent_locality_id_ are obviously bogus.
<khuck>
i.e. parent_locality_id_ = 395919568 on a 1 locality run
diehlpk has quit [Ping timeout: 248 seconds]
<hkaiser>
khuck: interesting
<hkaiser>
how can I reproduce this?
<hkaiser>
ahh, I think I know what's happening
<hkaiser>
doh
<hkaiser>
let me think
elfring has joined #ste||ar
gedaj has quit [Ping timeout: 264 seconds]
gedaj has joined #ste||ar
EverYoung has quit [Ping timeout: 265 seconds]
EverYoung has joined #ste||ar
aserio has quit [Ping timeout: 255 seconds]
jaafar has joined #ste||ar
<khuck>
hkaiser: one way to expose it is configure with APEX, then build Phylanx and run lra_csv with the breast cancer data set. I haven't found a smaller test case that replicates it.
<hkaiser>
khuck: I think what happens is that a thread is created as a staged thread first and by the time it actually gets instantiated the parent threead is already gone
EverYoung has quit [Ping timeout: 255 seconds]
<khuck>
but parent_thread_id_ is not null, so I think it's still there
<hkaiser>
no
<hkaiser>
heller: change thread-ids from actually keeping the object alive to plain pointers :/
<hkaiser>
so it's his fault
<khuck>
ah
<khuck>
so a staged thread shouldn't "retain" its parent_thread_id_ at all, because it won't be around later
<hkaiser>
I knew there was a reason, but when he changed it I couldn't remember why we were keeping the thread object alive
<hkaiser>
khuck: what information do you need from a parent thread?
<khuck>
parent_thread_id_.get()->get_apex_data()
<khuck>
but the thread_data is gone
<khuck>
only for dependency tracking. So if the parent isn't going to wait for the child, there's no reason to track it.
<hkaiser>
K-ballo: I understand
<hkaiser>
khuck: ^^
<hkaiser>
sorry K-ballo
<khuck>
:)
<K-ballo>
...
<khuck>
I haven't been on IRC for a few months, so you'll have to get used to tabbing twice. :)
<hkaiser>
khuck: yah
<hkaiser>
khuck: I need to think about how this can be solved
<khuck>
np
<khuck>
hkaiser: I was wondering if storing the m_apex_data in the thread_data is the right thing to do
<hkaiser>
khuck: I think it does make sense to track the parent even if it's not around anymore once the child is run
<hkaiser>
khuck: what alternative do you see?
<hkaiser>
(without having a separate map holding that)
<khuck>
hkaiser: store it somewhere else, where it doesn't need to be updated at the rebind process
<hkaiser>
khuck: what we could do is to call into apex the moment the staged thread is created at which point the apex data is still accessible
<khuck>
somewhere more persistent to the task at hand
<khuck>
yes
<khuck>
hkaiser: in the thread_init_data?
<hkaiser>
khuck: sec
<hkaiser>
khuck: where is apex currently called when a thread is created?
<khuck>
hkaiser: thread_data constructor, and rebind_base