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/
balaje has joined #ste||ar
balaje has quit [Client Quit]
K-ballo has quit [Quit: K-ballo]
shubham has joined #ste||ar
shubham has quit [Quit: Connection closed for inactivity]
zao has quit [*.net *.split]
mi1998[m] has quit [*.net *.split]
bobakk3r_ has quit [*.net *.split]
jbjnr has quit [*.net *.split]
ms[m]1 has quit [*.net *.split]
rori has quit [*.net *.split]
old_man[m] has quit [*.net *.split]
tiagofg[m] has quit [*.net *.split]
pedro_barbosa[m] has quit [*.net *.split]
diehlpk_work has quit [*.net *.split]
jaafar has quit [*.net *.split]
parsa has quit [*.net *.split]
jpinto[m] has quit [*.net *.split]
heller1 has quit [*.net *.split]
gdaiss[m] has quit [*.net *.split]
gnikunj[m] has quit [*.net *.split]
srinivasyadav227 has quit [*.net *.split]
Vir has quit [*.net *.split]
wash[m] has quit [*.net *.split]
tarzeau_ has quit [*.net *.split]
itn[m] has quit [*.net *.split]
sestro[m] has quit [*.net *.split]
jedi18[m] has quit [*.net *.split]
gonidelis[m] has quit [*.net *.split]
klaus[m] has quit [*.net *.split]
sbalint[m] has quit [Ping timeout: 245 seconds]
k-ballo[m] has quit [Ping timeout: 245 seconds]
bobakk3r_ has joined #ste||ar
tiagofg[m] has joined #ste||ar
tiagofg[m] has quit [Ping timeout: 252 seconds]
zao has joined #ste||ar
parsa has joined #ste||ar
jaafar has joined #ste||ar
wash[m] has joined #ste||ar
Vir has joined #ste||ar
diehlpk_work has joined #ste||ar
tarzeau_ has joined #ste||ar
jpinto[m] has joined #ste||ar
jedi18[m] has joined #ste||ar
ms[m] has joined #ste||ar
rori has joined #ste||ar
klaus[m] has joined #ste||ar
gnikunj[m] has joined #ste||ar
sbalint[m] has joined #ste||ar
sestro[m] has joined #ste||ar
pedro_barbosa[m] has joined #ste||ar
jbjnr has joined #ste||ar
heller1 has joined #ste||ar
srinivasyadav227 has joined #ste||ar
tiagofg[m] has joined #ste||ar
itn[m] has joined #ste||ar
gdaiss[m] has joined #ste||ar
k-ballo[m] has joined #ste||ar
mi1998[m] has joined #ste||ar
old_man[m] has joined #ste||ar
gonidelis[m] has joined #ste||ar
K-ballo has joined #ste||ar
<gonidelis[m]> K-ballo: i am trying to understand the difference
<gonidelis[m]> Do views optimize the calculation?
<gonidelis[m]> somehow
<gonidelis[m]> K-ballo: i really need your advice on this answer of mine https://stackoverflow.com/a/67020564/8242494
<gonidelis[m]> delete it or improve it?
<K-ballo> "before ranges-v3" is making a most odd copy of the vector, "after ranges-v3" isn't
<K-ballo> the "before" equivalent would be simply `std::transform(y.begin(), y.begin() + 2, y.begin(), pow);`
<gonidelis[m]> K-ballo: hm right. I am changing that
<gonidelis[m]> K-ballo: now my question is, in terms of performance
<gonidelis[m]> Is Niebler's views code, just a "rephrasing" of the "before range-v3" verbal code?
<K-ballo> pretty much yes
<K-ballo> how does performance factor into that?
<gonidelis[m]> K-ballo: I am asking whether it factors
<gonidelis[m]> if it does not, then parallelization should be trivial
<K-ballo> no idea what you are thinking
<gonidelis[m]> K-ballo: look
<K-ballo> maybe try https://quick-bench.com/ ? but I don't see how that relates to the rephrasing
<gonidelis[m]> Niebler was bragging that his range-v3 library makes code loop and branch free
<gonidelis[m]> but if the underlying execution flow is the same, then ranges only faciliate the writer and the reader
<gonidelis[m]> and not the performance
<K-ballo> loop and branch free are factors of expressiveness and clarity, not performance
<gonidelis[m]> ok great
<gonidelis[m]> so argument no.1 - Expressiveness
<gonidelis[m]> so what's the problem with parallelizing a range algorithm
<gonidelis[m]> i thought it was that the parallel algorithm wouldn't know how to handle each and every different view given
<K-ballo> there are no inherent problems with parallelizing range algorithms
<gonidelis[m]> grrr
<gonidelis[m]> K-ballo: doesn't that make my SO answer completely invalid
<gonidelis[m]> ?
<K-ballo> maybe? I don't think I understand it
<K-ballo> the question is mostly procedural
<gonidelis[m]> you don't understand the answer?
<K-ballo> not really
<gonidelis[m]> i am deleting it
<gonidelis[m]> now, I don't understand... what's the problem then?
<gonidelis[m]> why don't we just wrapt the views in a range-like form and then just pass them the exec-policy
<K-ballo> there is no actual problem
<gonidelis[m]> hkaiser was mentioning using loop fusion
<K-ballo> and that simple transformation would be a pretty bad paralelization
<K-ballo> range algorithms can do parallelization much better than fork-join style traditional algorithms
<gonidelis[m]> <K-ballo "and that simple transformation w"> why???
<K-ballo> they already have laziness going on for them
<K-ballo> take your simplistic transform example and combine some other operation
<gonidelis[m]> i guess views::take is not an "other operation"
<K-ballo> for the most simplistic case, there's no real difference with "showing down an execution policy"
<K-ballo> *shoving
<gonidelis[m]> <K-ballo "and that simple transformation w"> ahh you were talking about my transform call
<gonidelis[m]> not about transforming a view to range
<K-ballo> yeah, that paper covers it pretty well
<gonidelis[m]> but... they don't really explain how they parallelize the fused operations
<gonidelis[m]> the op's are fused due to pipelining but then... it's like range-v3 provides them with ready-to-parallelize data structures
nanmiao has joined #ste||ar
shubham has joined #ste||ar
shubham has quit [Quit: Connection closed for inactivity]
nanmiao has quit [Quit: Connection closed]