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/ | GSoD: https://developers.google.com/season-of-docs/
K-ballo has quit [Quit: K-ballo]
hkaiser has joined #ste||ar
hkaiser has quit [Ping timeout: 276 seconds]
Coldblackice has joined #ste||ar
Coldblackice_ has quit [Ping timeout: 265 seconds]
jbjnr_ has joined #ste||ar
jbjnr_ has quit [Ping timeout: 245 seconds]
jbjnr_ has joined #ste||ar
rori has joined #ste||ar
nikunj has joined #ste||ar
jbjnr_ has quit [Ping timeout: 264 seconds]
Vir has quit [Ping timeout: 246 seconds]
Vir has joined #ste||ar
K-ballo has joined #ste||ar
nikunj97 has joined #ste||ar
nikunj has quit [Ping timeout: 264 seconds]
nikunj97 has quit [Ping timeout: 264 seconds]
jbjnr_ has joined #ste||ar
nikunj97 has joined #ste||ar
<jbjnr_> zoom link for thomas' talk today https://cscs.zoom.us/my/cscscrgf
nikun__ has joined #ste||ar
nikunj has joined #ste||ar
nikunj97 has quit [Ping timeout: 245 seconds]
nikun__ has quit [Ping timeout: 264 seconds]
nikunj has quit [Ping timeout: 245 seconds]
<simbergm> are you planning to use them?
<simbergm> they make schedulers depend on the partitioner but the question is: remove or rewrite?
aserio has joined #ste||ar
hkaiser has joined #ste||ar
<heller> simbergm: it looks like they don't use any state of the scheduler, do they?
jbjnr_ has quit [Ping timeout: 250 seconds]
<simbergm> heller: good point, they wouldn't need to be there at all
<simbergm> I suspect they can go though
nikunj has joined #ste||ar
<hkaiser> heller: btw, I don't think contexts should expose any way of submitting a task to them
<heller> hkaiser: what do you propose?
<hkaiser> they expose a executor() function that can be used to do that
<hkaiser> so executors are the submission interface, not contexts
<heller> I agree
<heller> I actually created that
<hkaiser> no, you expose a post() method from your context
<heller> that makes it easy to actually define a generic executor that uses contexts
<hkaiser> also, stackfull is now equal in perf to master, stackless about 7-8% faster than master
<heller> so the contexts are the customization points
<hkaiser> no
<hkaiser> contexts are the owners of the execution resource
<hkaiser> like thread_pools
<heller> so you'd rather create one executor for each context?
<hkaiser> yes
<hkaiser> possibly more than one
<hkaiser> executors do not own the execution resource, they are shims that have a backdoor into the context to submit things
<heller> the way I have written it right now, is that you can get a generic executor that posts to a specific context
<hkaiser> sure
<hkaiser> I don't think this is right
<heller> I have trouble imagining that shim otherwise
<heller> this way, we have a minimal set of customization points, and there's still possibilities to write different, context specifc executors
<hkaiser> we have that as well even if contexts don't have a public post() methond
<heller> so you'd be fine if the post method was private?
<hkaiser> heller: pls see the static_thread_pool in P0433
<hkaiser> that gives you a sense of what contexts should expose
<heller> ok
<heller> I see, so we would build different executors based on the generic one that was returned by the executor() function?
<heller> or the sender or whatever
<heller> TBH, this all looks overly complicated
weilewei has joined #ste||ar
<weilewei> I tried to run a hello world program with HPX and found this error: https://gist.github.com/weilewei/53094c897cd4d332acc64f7f064b8360
<weilewei> what could be the reasons?
<zao> weilewei: I recommend spelling "threads" correctly :P
<simbergm> unrecognised option '--hpx:threasd=1'
<simbergm> we could do better than a segfault on unrecognized options though...
<heller> the error messages are just too long
<weilewei> same thing without the thread option
<heller> hkaiser: so where is the benefit of doing it the P0433 way?
<heller> hkaiser: is there consensus to move along with P0433?
<heller> and it's P0443
aserio has quit [Ping timeout: 250 seconds]
<heller> hkaiser: I'm sorry, I am not really sold on the thread pool interface in P0443
<hkaiser> heller: reason: separation of concerns
<hkaiser> contexts manage the resources, executors do the submission to those
<heller> so I guess it's just yet another class you'd write
<heller> instead of a function
<hkaiser> well, no user will write contexts, some might write executors, but even that is only done by a few
<heller> I am more concerened to our effort ;)
<hkaiser> come on
<hkaiser> we're not afraid of creating an hpx module from a single file, and now you balk at this
<heller> it's also about the adoption to this mechanism from other runtime authors
<hkaiser> heller: the key is to do what the standard does
<heller> since it is not set in stone, we can still influence it though ;)
<hkaiser> heller: yes, now is the time!
<hkaiser> they are about to agree on the results of the fifth iteration - that's where you come in and make them start over again ;-)
<heller> :P
nikunj has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
<heller> hkaiser: "XXX TODO The receiver concept..." so there we go
<hkaiser> do it! go ahead!
aserio has joined #ste||ar
nikunj has quit [Ping timeout: 264 seconds]
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 240 seconds]
K-ballo1 is now known as K-ballo
nikunj has joined #ste||ar
rori has quit [Quit: WeeChat 1.9.1]
weilewei has quit [Remote host closed the connection]
nikunj has quit [Ping timeout: 250 seconds]
aserio has quit [Ping timeout: 250 seconds]
weilewei has joined #ste||ar
aserio has joined #ste||ar
hkaiser has quit [Ping timeout: 250 seconds]
<diehlpk_work> jbjnr, Why is the libfabric parcelport on cray as a default on?
<zao> weilewei: I'm guessing that your builds and tests run properly on a system that's not Summit?
weilewei has quit [Remote host closed the connection]
hkaiser has joined #ste||ar
jbjnr_ has joined #ste||ar
<jbjnr_> simbergm:correct - those functions could be removed. It'd be nice if we had a folder of deprecated snippets that might one day be useful, just in case we did ever need them again and could find them.
<jbjnr_> If you need to remove them, go ahead.
aserio has quit [Ping timeout: 250 seconds]
aserio has joined #ste||ar
weilewei has joined #ste||ar
<weilewei> zao my hpx builds and hpx tests run properly on Summit
<weilewei> I am testing my code on Summit right now zao
<diehlpk_work> hkaiser, Sagiv tries to build hpx master and it fails with hpx_wrap is not built by this project
<hkaiser> diehlpk_work: ok, pls ask him to create a ticket describing a) his system, compiler, etc. b) the steps to reproduce his issue
weilewei has quit [Remote host closed the connection]
weilewei has joined #ste||ar
<heller> diehlpk_work: it's on by default because it's faster than MPI and we know it's works on cray interconnects
<diehlpk_work> heller, But do we want that new users have to struggle with it?
<diehlpk_work> Why do we not have a cmake tool chain for MPI and libfabric
<heller> Feel free
<heller> I think it was even in the default environment on cori
weilewei has quit [Remote host closed the connection]
<heller> Or available as a module
<heller> Building it yourself is also easy
<heller> Shouldn't cause struggles, I definitely recommend using it
Coldblackice has quit [Read error: Connection reset by peer]
Coldblackice has joined #ste||ar
<heller> diehlpk_work: I'm sure the admins on summit will be happy to install it for you
<diehlpk_work> heller, We might want to document this somewhere
<heller> Sure
aserio has quit [Quit: aserio]
hkaiser has quit [Ping timeout: 245 seconds]
jbjnr_ has quit [Ping timeout: 246 seconds]
hkaiser has joined #ste||ar
hkaiser has quit [Ping timeout: 250 seconds]
diehlpk_work has quit [Remote host closed the connection]