K-ballo 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/
nanmiao has joined #ste||ar
hkaiser has joined #ste||ar
jehelset has joined #ste||ar
K-ballo has quit [Ping timeout: 240 seconds]
hkaiser has quit [Quit: bye]
nanmiao has quit [Quit: Connection closed]
bita has joined #ste||ar
bita has quit [Ping timeout: 276 seconds]
bita has joined #ste||ar
bita has quit [Ping timeout: 258 seconds]
<gonidelis[m]>
ms[m]: what's the execution namespace for? I mean what's the difference between an algo under `parallelism/algorithms` and an algo under `parallelism/execution`?
<ms[m]1>
gonidelis[m]: it's for things that are proposed to be in std::execution, i.e. we just use execution if something is proposed to be in execution ;)
<ms[m]1>
generally though, things under std::execution are not parallel algorithms, but often concurrent
<ms[m]1>
almost everything directly in std operates on ranges/iterators and is potentially parallelizable
<ms[m]1>
*almost all the algorithms that we have directly in hpx::
<gonidelis[m]>
ms[m]: so, about the `|` operator overload you provided... that's for the concurrent algos, right?
<gonidelis[m]>
ahh i don't get it. why are `seq` and `par` conform to these constraints and `task(par)` does not?
<gonidelis[m]>
do^^ `seq` and `par` [...]
<K-ballo>
seq/par don't change the signature nor the semantics
<gonidelis[m]>
the question is: how `task(par)` does?
<gonidelis[m]>
plus seq/par do work as overloading mechanism in order to dispatch to the proper base implementation (ok that's for the vendor to decide, but still)
<K-ballo>
dispatching to the implementation is an implementation detail, that's fine
<K-ballo>
do you know what a signature is?
<gonidelis[m]>
it's an instance of a function overload ?
<gonidelis[m]>
not instance, definition
<K-ballo>
just the type
<K-ballo>
since policy isn't (meant to be) an overloading mechanism, it can't possibly affect parameters nor return type
<gonidelis[m]>
wait... but some ranges overloads have different return types copmared to their std brothers
<K-ballo>
those are overloads
<K-ballo>
(and totally un-policied, so not really related either)
<K-ballo>
overloads can have different parameters and/or return type, policies are not about overloading
<gonidelis[m]>
but policies do overload, as if a std::for_each(...) call differs from a std::for_each(par, ...) which differs from a ranges::for_each() call. they pick different overloads
<K-ballo>
not sure what that's trying to say
<K-ballo>
only one of those overloads does policies
<gonidelis[m]>
ok...what if we proposed for the asynchronous algos (in order to be bale to receive async exec policies) to exist under a different namespace (async:: or hpx:: or sth idk)
<gonidelis[m]>
?
<K-ballo>
that's effectively what you'd have to end up with
<K-ballo>
a true overload
<gonidelis[m]>
and is that bad?
<K-ballo>
not necessarily
<gonidelis[m]>
it sounds like a proposal to me
hkaiser has joined #ste||ar
bita has joined #ste||ar
nanmiao has joined #ste||ar
<K-ballo>
cpu_mask ought to be a real type
<hkaiser>
isn't that just used for the configuration tests?
<hkaiser>
ahh, no - it's a int64_t normally
<K-ballo>
I doubt the bitset and dynamic bitset implementations are well tested
<K-ballo>
there should be three different implementations all the time, then just change some alias
<K-ballo>
maybe even just two
shubham has joined #ste||ar
<hkaiser>
K-ballo: the three implementations are all useful in their own way
<shubham>
Okay
<hkaiser>
the use of the uint64_t is just an optimization
<K-ballo>
that's why maybe just two
<K-ballo>
there's two cases: fixed and dynamic (and furthermore dynamic should be implemented as fixed + extra)
<hkaiser>
well, not quite
<hkaiser>
there is the ncore <= 64 case covered by the uint64, and the ncores > 64 fixed and dynamic cases
<K-ballo>
the ncore <= 64 case is the fixed case
<K-ballo>
or is it dynamic ?
<K-ballo>
with upper bound
<hkaiser>
no, it's fixed to ncores <= 64
<hkaiser>
well, yes dynamic with upper bound describes it as well
<K-ballo>
I thought it was just reimplementing bitset on top of an uint64_T
<hkaiser>
in that sense all cases are dynamic, two with upper bounds
<hkaiser>
K-ballo: the comand line options --hpx:threads=N determines how many bits are actually used
<hkaiser>
you can think of uint64 being an optimization for the bitset case
<hkaiser>
nowadays bitset might be good enough for even this case, however
<hkaiser>
probably depends on the underlying type use by bitset
<hkaiser>
K-ballo: in any case, I agree that the cpu_mask should be a proper type
jehelset has quit [Remote host closed the connection]
<gnikunj[m]>
hkaiser: hey! sorry, I couldn't join weekly meeting today as well :/
<hkaiser>
np
<hkaiser>
we moved the meeting up 30 minutes, I hope this will work for you
<gnikunj[m]>
can we please change the timings so that it doesn't come up in my 7:30-9PM time?
<gnikunj[m]>
well moving up 30min only makes it worse ;_;
<hkaiser>
uhh, that will not work, sorry
<hkaiser>
too late
<gnikunj[m]>
crap. I'll try my best to join in next week so we can discuss a time that may suit all of us. Would that be alright?
<hkaiser>
we can't move it down because of other conflicts
<gnikunj[m]>
I see :/
<hkaiser>
yes, that sounds good
shubham has quit [Quit: Connection closed for inactivity]
nanmiao has quit [Quit: Connection closed]
nanmiao has joined #ste||ar
bita has quit [Read error: Connection reset by peer]