<hkaiser>
heller: but why hpx::mpi::invoke and not hpx::mpi::async?
<heller>
hkaiser: async has the connotation of an RPC, at least for me
<hkaiser>
or even hpx::async(hpx::mpi::executor, ...
<heller>
which that one isn't
<heller>
this is just wrapping the async MPI functions to return a future
<hkaiser>
async has nothing in common with RPC
<heller>
it has in our context
<hkaiser>
it could be RDMA as well, or anything else
<hkaiser>
it simply asynchronously does something
<heller>
asynchronous operations: yes
<hkaiser>
no
<hkaiser>
it asynchronously invokes an action
<heller>
std::async and hpx::async launch tasks. hpx::async can launch tasks remotely
<hkaiser>
no, it launches an action which happens to do remote things
<heller>
I wouldn't overload terms here
<heller>
in my book, an action is all about doing RPC
<hkaiser>
it could do RDMA or trigger a local operation
<heller>
well, a procedure does those things, true
<heller>
however, to make MPI action aware, it requires far more things
<heller>
and that's not the point here ... the point is more about how to be able to use futures with thin layers over exisiting software ecosystems
<hkaiser>
well, sure
<heller>
I think the first step is to show that HPX as its own software ecosystem, is capable enough to adapt to other, existing, or even emerging ones
<heller>
to not only open up a migration path, but to use its different modules as building blocks without imposing too much
<heller>
does this make sense?
<hkaiser>
sure
<hkaiser>
btw stackfull vs. stackless
<hkaiser>
500000 hpx threads: 2.6s vs. 2.4s
<hkaiser>
as expected, 10%% improvment
<heller>
8 :P
<heller>
can you compare the numbers to master as well please?
jbjnr_ has quit [Ping timeout: 252 seconds]
<hkaiser>
yah, next on my list
<hkaiser>
heller: master is at 2.55s
<heller>
hkaiser: interesting
<hkaiser>
heller: this is obviously no thorough analysis yet
<hkaiser>
just a quick manual run
<heller>
hkaiser: I think the stackless tasks will really shine after streamlining the scheduling loop and task states
<hkaiser>
absolutely
<hkaiser>
needs more work, definitely
<heller>
I think they might even be a perfect fit for a custom execution agent/execution context
<heller>
which should help with that
jbjnr_ has joined #ste||ar
hkaiser has quit [Ping timeout: 250 seconds]
aserio has quit [Quit: aserio]
hkaiser has joined #ste||ar
<hkaiser>
heller: those _are_ a different agent
<heller>
hkaiser: exactly. they almost share nothing with thread_data ;)
<hkaiser>
thread_data ?
<hkaiser>
what do you mean?
<heller>
that your implementation of stackless tasks derive from thread_data, or did I misunderstand something?
<hkaiser>
they do, yes
<heller>
so what I wanted to say, we have thread_data representing one agent, and the stackless ones representing another
<hkaiser>
heller: hmmm, not really
<hkaiser>
thread_data_stackfull is one thread_data_stackless the other, both are derived from thread_data
<heller>
sure, that's how you implemented it
<heller>
I'd argue however, that they shouldn't share the same base class
<hkaiser>
only implementation sharing, a) didn't want to copy, b) wanted to keep the state management non-virtual
<hkaiser>
I think you're recreating the executor interface here
<heller>
partially, yes
<hkaiser>
post() is an executor API function
<hkaiser>
why, then?
<heller>
still two different things
<hkaiser>
k
<heller>
a context should expose a default executor eventually
<heller>
that is, a context needs to be able to spawn agents
<heller>
the post function is a strawman, didn't come up with a better name
<hkaiser>
sure
<hkaiser>
executors are lihgtweight wrappers for contexts, so this is probably ok
<heller>
but you should be able to instantiate different executors using the same context
<heller>
right
<heller>
executors are the API to spawn agents on contexts
<hkaiser>
nod
<heller>
closing the circle ... stackless tasks could be represented by their own context
<heller>
spawning their specific agents
<hkaiser>
nobody has said that contexts couldn't spawn various agents
<hkaiser>
and I think there is a use for that
<heller>
hmm
<heller>
having a one to one relationship, would simplify the API
<heller>
since the context carries the information on what agents to spawn, there's no need for additional parameters to distinguish between the agents to spawn and we don't impose the requirement for diferent contexts to support spawning of various agents
<hkaiser>
so even different stack sizes would imply using different contexts?
<heller>
good question
<heller>
so would that rather be a property of the executor then?
<heller>
how do we handle different stack sizes for locally launched tasks right now?
<hkaiser>
it's a parameter to register_thread
<hkaiser>
heller: well, it might be a property of the executor, but even then you have to have a way to pass it on to the context
<heller>
right, but is a different stack size really a different agent?
<heller>
isn't stacksize a different thing than stackless vs. stackfull?
<hkaiser>
same for priorities, scheduling-hints, etc.
<hkaiser>
shrug
<hkaiser>
I could imagin gthat a user might want to mix stackfull and stackless in the same paralell context/region
<heller>
the problem I have with the stack size is that they essentially leak implementation details
<heller>
stackless/stackfull in parallel regions: yes, probably
<hkaiser>
hmm, it's similar to priorities, no?
<heller>
I don't think so, different priorities for different tasks can stem from algorithmic need
<heller>
s
<heller>
stack sizes are a limitation of the underlying coroutine machinery
<heller>
what do stack sizes mean for stackless tasks?
<hkaiser>
pthreads have an API for stacksizes as well
<heller>
windows fibers don't
<hkaiser>
they do
<heller>
ok
<heller>
std::thread doesn't, at least
<hkaiser>
yah, because its meant to be platform independent
<hkaiser>
anyways
<heller>
let's sleep over it a few nights...
<hkaiser>
right
<hkaiser>
in any case, your stuff is a game changer
<heller>
let's see how the acceptance is tomorrow
<heller>
potentially a game changer, we just have to carry it through
<heller>
plus, I still have to check how it relates to the whole new future API that eric bryce and david are cooking up
<hkaiser>
their stuff is lower level
<heller>
even orthogonal to this
<hkaiser>
right
<hkaiser>
it's a infrastructure to implement things like futures considering heterogeneous contexts/executors