hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
hkaiser has quit [Quit: Bye!]
Yorlik__ has joined #ste||ar
Yorlik_ has quit [Ping timeout: 248 seconds]
tufei__ has joined #ste||ar
tufei_ has quit [Ping timeout: 255 seconds]
Neeraj has joined #ste||ar
Neeraj has quit [Quit: Client closed]
Neeraj has joined #ste||ar
Neeraj has quit [Client Quit]
Neeraj has joined #ste||ar
Neeraj has quit [Quit: Client closed]
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 276 seconds]
K-ballo1 is now known as K-ballo
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 276 seconds]
K-ballo1 is now known as K-ballo
HHN has joined #ste||ar
HHN has quit [Client Quit]
HHN has joined #ste||ar
HHN is now known as HHN93
HHN93 has quit [Quit: Client closed]
HHN93 has joined #ste||ar
HHN93 has quit [Client Quit]
HHN93 has joined #ste||ar
HHN9363 has joined #ste||ar
HHN93 has quit [Ping timeout: 260 seconds]
HHN9363 has quit [Client Quit]
hkaiser has joined #ste||ar
K-ballo has quit [Ping timeout: 248 seconds]
K-ballo has joined #ste||ar
HHN93 has joined #ste||ar
<HHN93> hpx::is_sequenced_execution_policy<ExPolicy> returns true for unseq execution policy, is this a fallback mechanism because unseq hasn't been implemented?
<hkaiser> HHN93: yes, it falls back to seq (unseq is a sequentially executing policy after all)
<hkaiser> i.e. doesn't use (task-)parallelism
<hkaiser> HHN93: so what do you mean by unseq not being implemented? the execution policy is implemented, some of the algorithms do not support it, however
<HHN93> if it falls back to seq, all of them execute the corresponding sequential implementation
<HHN93> right?
<hkaiser> assuming I'm understanding your question correctly, yes
<HHN93> got it, thank you
<Aarya[m]> Hi I feel like exploring the "Conflict (Range-Based) Locks" GSoC project. Can anyone guide me how to go about it :)
Yorlik__ is now known as Yorlik
<hkaiser> Aarya[m]: the person that knows the most about this project is not able to mentor this year, we will have to take down this project, sorry
tufei__ has quit [Quit: Leaving]
<HHN93> hkaiser, right now we simply dispatch based on seq or par, shouldn't we also consider unseq? (https://github.com/STEllAR-GROUP/hpx/blob/master/libs/core/algorithms/include/hpx/parallel/algorithms/detail/dispatch.hpp#L200)
<Yorlik> I made an attempt to create a safe pointer wrapper that is nullable, non owning and it supports pointer tagging. Ideas? https://gist.github.com/McKillroy/2a6963b98709a7a1a4a951d44f5c0aa6
tufei has joined #ste||ar
<hkaiser> HHN93: is_sequenced_execution_policy will be true for unseq as well
<hkaiser> Yorlik: why nullable?
<HHN93> yes, i have observed that. But it seems wrong right?
<hkaiser> why?
<HHN93> there might be functions which can't be executed unseq
<Yorlik> hkaiser: Sometimes you want to return from a function and have no result.
<hkaiser> HHN93: we have two overarching implementations: one that does tasking, and one that does not
<hkaiser> Yorlik : use optional?
<Yorlik> Optional uses 16 bytes. My pointer only 8 :)
<hkaiser> ;-)
<hkaiser> makes sense
<HHN93> HHN93: we have two overarching implementations: one that does tasking, and one that does not
<HHN93> I am sorry, can you please elaborate?
<hkaiser> non-tasking policies are seq, simd, and unseq, while tasking policies are par, par_simd, and par_unseq
<Yorlik> Just updated the gist - there was a nonsensical assignment operator that was const :P
<Yorlik> hkaiser: That wrapper is for my Spatial Indexing stuff - so the 8 saved bytes really are important.
<hkaiser> Yorlik: I wouldn't use operator T&() if I don't absolutely have to
<Yorlik> hkaiser: What's the issue with it?
<hkaiser> you might run into surprising conversions in places where you don't expect for them to happen
<hkaiser> I'd rather use an explicit .get() or similar
<K-ballo> Yorlik: look at proposed observer_ptr for interface
<Yorlik> K-ballo - Will do - thanks!
<Yorlik> K-ballo - I see - that observer ptr is pretty close to what I wanted - except I added pointer tagging as an option to it.
<Yorlik> But I'll brish my interface to conform with the proposal.
<K-ballo> yeah, it's a non-owning pointer
<Yorlik> brush
<K-ballo> the dumbest smart pointer
<Yorlik> It really fills a gap. Neither reference wrapper not optional can really replace it.
<Yorlik> I had a nullable reference type, but I like this approach better.
<HHN93> non-tasking policies are seq, simd, and unseq, while tasking policies are par, par_simd, and par_unseq
<HHN93> the function to be called for simd and seq execution should be different right?
<Yorlik> hkaiser: Just removed the conversion operator and all tests and examples are still fine - so i guess. I'll ditch it :)
<hkaiser> Yorlik: nod, good
<hkaiser> HHN93: on the top level, they are the same, the dispatching happens on lower levels (see the loop implementations)
<Yorlik> hkaiser: How's your schedule this weekend? Any chance to horribly abuse your time for Spatial Indexing madness?
<hkaiser> let's play it by ear tomorrow
<Yorlik> Nice :)
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 248 seconds]
K-ballo1 is now known as K-ballo
HHN93 has quit [Quit: Client closed]