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
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 240 seconds]
K-ballo1 is now known as K-ballo
Yorlik_ has joined #ste||ar
Yorlik has quit [Ping timeout: 276 seconds]
diehlpk has joined #ste||ar
hkaiser has quit [Quit: Bye!]
diehlpk has quit [Quit: Leaving.]
K-ballo has quit [Ping timeout: 240 seconds]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
diehlpk has joined #ste||ar
<gnikunj[m]> hkaiser: srinivasyadav227 : won’t make it to today’s meeting. Another meeting scheduled for the time :/
<hkaiser> gnikunj[m]: we cancelled it anyways
<hkaiser> we will also skip this meeting for the next two weeks
<gnikunj[m]> Ohh, don’t know how it shows up in my calendar still
<gnikunj[m]> Thanks for letting me know!
<hkaiser> gnikunj[m]: it wil go away from your calendar in a minute
<hkaiser> sorry for the late notice
<dkaratza[m]> hkaiser: my 2 PRs are ready, you can check and possibly merge
<hkaiser> dkaratza[m]: will do today, thanks
<hkaiser> gdaiss[m]: we cancelled today's meeting, sorry for not notifying in time
<gdaiss[m]> hkaiser: Yeah, srinivas just told me as well! Is the meeting on Friday canceled as well?
<hkaiser> gdaiss[m]: I have not cancelled that one, I think - even if Srinivas can't join - we should have it to talk to Joel
<gdaiss[m]> okay, I'll be there! Still at 9am CDT?
<hkaiser> gdaiss[m]: yes
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 255 seconds]
K-ballo1 is now known as K-ballo
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
<gonidelis[m]> K-ballo: hkaiser do you know the proposal for `in_fun_result`. I wanna find out if its implemented in clang14
<K-ballo> ranges?
<gonidelis[m]> guh
<gonidelis[m]> where is `namespace std { `?
<hkaiser> gonidelis[m]: _LIBCPP_BEGIN_NAMESPACE_STD
<gonidelis[m]> ah
<gonidelis[m]> cannot be found by my compiler, need to look into it
<hkaiser> gonidelis[m]: btw, the parallel versions of for_each (I assume you're trying to look at that) shouldn't return an in_fun_result
<gonidelis[m]> ....
<gonidelis[m]> you assumed correctly
<gonidelis[m]> hkaiser: why isn't it in_fun_result?
<gonidelis[m]> what is our reason for that?
<hkaiser> in_fun_result contains the function object that was passed to for_each
<hkaiser> if it contains state and for_each is parallelised, then you will have several instances of F (one for each generated chunk)
<hkaiser> which of those would you return?
<gonidelis[m]> yup scratch that
<gonidelis[m]> no no you are right!
<gonidelis[m]> wow
<gonidelis[m]> reverse the question: why the need to pack the iterator with F in a single type result to begin with?
<hkaiser> for sequential execution F could be used to accumulate state while iterating, so why not return it?
<gonidelis[m]> wow
<gonidelis[m]> wow wow wow
<gonidelis[m]> we return the Iterator in the parallel ranges version
<hkaiser> yes
<gonidelis[m]> in the parallel non-ranges version void is being returned
<gonidelis[m]> why people?
<gonidelis[m]> i would love some more consistency
<hkaiser> that's because the range used to call for_each could be a (iter, sentinel), in which case the returned value would be the iterator pointing to the position identified by the sentinel
<gonidelis[m]> alright, then why not std::for_each(par, ...) return iter?
<hkaiser> gonidelis[m]: generally, the algorithms return as much information as possible, this may avoid for the user having to recalculate things that the algorithm already has
<gonidelis[m]> very nice
<gonidelis[m]> so my question becomes stronger
<gonidelis[m]> why do the parallel non ranges return void
<gonidelis[m]> ?
<hkaiser> gonidelis[m]: I don't know, I consider this a bug - most likely for consistency with std::for_each(iter, iter, f)
<gonidelis[m]> awful
<hkaiser> gonidelis[m]: the question really is, what should for_each() 'return' if used in a sender/receiver chain?
<hkaiser> ie. what's returned by: just(rng, f) | for_each(par) | sync_wait();?
<hkaiser> before we don't answer this question, everything else doesn't make sense
<gonidelis[m]> either void or iter. either case we do the same handling, send it over to sync_wait(), no?
<hkaiser> gonidelis[m]: if you want to use s/r algorithms the same way as range-algorithms, then they should return the range
<hkaiser> just(rng) | for_each(par, f1) | transform(par, f2)
<gonidelis[m]> very nice
<gonidelis[m]> lets start with that
<gonidelis[m]> and then build on top of it
<gonidelis[m]> you are right
<gonidelis[m]> the range, or an iterator to the range?
<hkaiser> what's an 'iterator to a range'?
<gonidelis[m]> iterator to the after the last element of the range maybe?
<hkaiser> ahh
<hkaiser> ok
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
diehlpk has quit [Client Quit]
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 244 seconds]
K-ballo1 is now known as K-ballo