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/
bita has quit [Ping timeout: 240 seconds]
jejune has quit [Quit: "What are you trying to say? That I can dodge bullets?" "No Neo, what I'm trying to say, is that when you are ready.....you won't have to"]
hkaiser has quit [Quit: bye]
K-ballo has quit [Quit: K-ballo]
hkaiser has joined #ste||ar
hkaiser has quit [Quit: bye]
nanmiao has quit [Quit: Connection closed]
diehlpk_work has quit [Read error: Connection reset by peer]
jejune has joined #ste||ar
jehelset has joined #ste||ar
jejune has quit [Quit: "What are you trying to say? That I can dodge bullets?" "No Neo, what I'm trying to say, is that when you are ready.....you won't have to"]
jehelset has quit [Remote host closed the connection]
<gonidelis[m]>
does anyone know what's the purpose of `hpx::for_loop` we have implemented
<gonidelis[m]>
i cannot find anything in the standard
<gnikunj[m]>
for_loop is an old one. It mimics the C++ for loops (as the name suggests).
<gnikunj[m]>
Also for_loop is blocking (returns a void) while for_each is asynchronous (returns a future<void> if parallel task policy). Just in case you're wondering what they difference between those two is.
<gonidelis[m]>
blocking?
<gonidelis[m]>
i think it returns the same `The for_loop algorithm returns a hpx::future<void> if the execution policy is of type sequenced_task_policy or parallel_task_policy and returns void otherwise. `
<gnikunj[m]>
it got changed then :p
<gnikunj[m]>
it was previously blocking iirc. Or I'm just being stupid.
<gonidelis[m]>
what's blocking?
<gonidelis[m]>
no you are not... you gave quite an insight
<gnikunj[m]>
asynchronous calls are calls that returns immediately. Blocking are those that completes execution and then return.
<gonidelis[m]>
ok got it thanks!
<gnikunj[m]>
HPX is all about asynchrony :D
M1ck3y has joined #ste||ar
<gonidelis[m]>
that's our asset
K-ballo has joined #ste||ar
M1ck3y has quit [Ping timeout: 240 seconds]
hkaiser has joined #ste||ar
M1ck3y has joined #ste||ar
M1ck3y has quit [Ping timeout: 240 seconds]
<jedi18[m]1>
hkaiser: Can I start working on the remaining algorithms as well?
<hkaiser>
jedi18[m]1: sure ;-)
<hkaiser>
please go ahead
<hkaiser>
got the hang of it?
<jedi18[m]1>
<hkaiser "got the hang of it?"> I think so! I few more would definitely help
<hkaiser>
:D
<jedi18[m]1>
I hope the PR is alright, right?
<hkaiser>
all is well - I approved it
<hkaiser>
just waiting for the tests to cycle
<gnikunj[m]>
jedi18[m] good work ;)
<jedi18[m]1>
Oh thanks! I've done adjacent_find as well so I'll create a PR for that too soon
<jedi18[m]1>
<gnikunj[m] "jedi18[m] good work ;)"> Thank you! :D
<hkaiser>
jedi18[m]1: and sorry for nitpicking
<jedi18[m]1>
That's not nitpicking, I understand how important formatting is for big projects
<jedi18[m]1>
Actually I had formatted it that way earlier, but messed up the clang format line so clang formatted it that way
<jedi18[m]1>
First and last iterators have always been of the same type everywhere I've seen, so I was wondering why those were different
<gonidelis[m]>
jedi18: thank you
<gonidelis[m]>
jedi18: thank you for asking this
<gonidelis[m]>
i was expecting it :)
<gonidelis[m]>
it's part of large adaptation to C++20 process taking place for the last 9 months or sth
<gonidelis[m]>
the^^
<gonidelis[m]>
the thing is that according to c++20 the algorithms should support different end type from start type
<gonidelis[m]>
in this way we implement the "sentinels", which beyond the fact that they can be end iterators, they could also be sentinel-values or distance (from the begin) values
<gonidelis[m]>
jedi18: so, by saying begin and end have been the same type "everywhere you 've seen" kinda hurts my feelings becaues that means we have a lot work left to do ;p
<jedi18[m]1>
Ohhh ok
<jedi18[m]1>
<gonidelis[m] "jedi18: so, by saying begin and"> Haha I meant every place adjacent_find is called, and I've barely seen any part of the codebase
<jedi18[m]1>
But I'd be happy to help with the process once I'm competent enough to :D
<gonidelis[m]>
rori_[m]: tests have only been added to the last 2 or 3 algos :)
<gonidelis[m]>
jedi18: as you can see there have already appeared a couple of fairly easy projects you could implement in order to diversify your familiarization
nanmiao has joined #ste||ar
<jedi18[m]1>
Cool!, I'll try those after the seperation algos then!
<gonidelis[m]>
separation algos?
<gonidelis[m]>
segmentation?
<jedi18[m]1>
Sorry, I meant seperating the segmented overloads of the algorithms
<hkaiser>
heh, I just realized, cpp-reference has algorithm implementations based on function objects, almost CPOs! that's cool - see Possible implementation on that page I just posted
<gonidelis[m]>
hkaiser: almost CPOs? :/ cpos are hardcode... this aint
<jedi18[m]1>
Will tag_invoke ever be a part of the standard?
<hkaiser>
jedi18[m]1: see p1895, most likely
<hkaiser>
one way or another the standard library will need a customization point mechanism, whether it will be tag_invoke is open
<jedi18[m]1>
Yeah I saw that the paper targetted c++23, but does that guarantee it will make it to the standard?
<hkaiser>
no
<jedi18[m]1>
Ohh ok
jehelset has quit [Remote host closed the connection]
jehelset has joined #ste||ar
<K-ballo>
tag_invoke is the best CPO mechanism we can implement with the current language
<K-ballo>
with a bit of luck the language will change instead
<gonidelis[m]>
what are other?
<K-ballo>
I should have said CP instead of CPO, but there's the original customization point paper as well
<K-ballo>
tag_invoke is making the original CP mechanism more palatable for users (library authors)
<K-ballo>
and there were non-object customization points before then
<gonidelis[m]>
so using func objects is an option
<K-ballo>
like the original swap, or std::hash<>
<gonidelis[m]>
hm
<K-ballo>
begin/end, tuple_size/tuple_element/get
<gonidelis[m]>
what's these?
<K-ballo>
more customization points, those are language ones, but same principle
<gonidelis[m]>
func objects are flexible
<gnikunj[m]>
hkaiser: returning executor created. On my way to refactor the resilience stuff to use that instead.
<hkaiser>
cool!
<gnikunj[m]>
btw, why is hpx::reduce blocking?
<gnikunj[m]>
should it not return future<T> instead of T?