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/
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
bita has quit [Ping timeout: 250 seconds]
jejune has joined #ste||ar
jehelset has quit [Ping timeout: 252 seconds]
shubham has joined #ste||ar
jejune has quit [Quit: "Everything that has a beginning, has and ending...neo."]
shubham has quit [Quit: Connection closed for inactivity]
<gonidelis[m]>
wouldn't it be more wise, for mechanisms who support pipelinined op's to actually keep the intermediate results (i read about `views::cache1`) just in case they actually need the result?
<gonidelis[m]>
sounds to me like we lose the benefits of laziness
<gonidelis[m]>
we were supposed not to compute things when not needed and we ended up computing things twice
<K-ballo>
you can't in general cache any T, you could for trivially copyable things, it could even potentially make sense for small trivially copyable things but it is tied to the cost of the computation
<gonidelis[m]>
ahh ok. yeah, the type matters
<gonidelis[m]>
K-ballo: but is Nicol Bolas's accpted answer relevant?
<gonidelis[m]>
he is talking about the distinction of moving and dereferencing a pointer
<K-ballo>
that answer explains why it needs to be called twice
<gonidelis[m]>
i don't understand why. i 've read it like 6 times
<K-ballo>
you don't understand ++ and * being different operations?
<gonidelis[m]>
what does `++` have to do with passing the calculated values to the next "pipelined" op?
<K-ballo>
consider how you'd implement each, for a filter view
<gonidelis[m]>
no i do understandt the distinction
<K-ballo>
there isn't actually a next pipelined op
<K-ballo>
filter is the last pipelined op in the chain
<gonidelis[m]>
yes
<gonidelis[m]>
so what does "to whoever is after it" mean?
<K-ballo>
no idea
<K-ballo>
where's that from?
<gonidelis[m]>
bocara's talk on cppcon 2020
<gonidelis[m]>
boccara*
<K-ballo>
never seen it
<gonidelis[m]>
it doesn't matter
<gonidelis[m]>
you said the answer responds fully to the question
<K-ballo>
did I?
<K-ballo>
I said the answer explains why it needs to be called twice, no?
<gonidelis[m]>
yes, since the question is why are the elements accessed twice
<gonidelis[m]>
from my prepspective, they are accessed twice becaue ranges::views pull data and lazily compute things
<gonidelis[m]>
<K-ballo "I said the answer explains why i"> yy
<gonidelis[m]>
what does being called twice have to do with the op distinction
<K-ballo>
it's about non-owning, rather than laziness, but they are related
<gonidelis[m]>
"But that access cannot be communicated to the caller of ++ because that caller only asked to position the iterator, not to get its value."
<gonidelis[m]>
hkaiser: thanks i will take a look right now
<K-ballo>
what's that? it's not an iterator
<gonidelis[m]>
oh it's from the same guy
<gonidelis[m]>
it does dereferencing and incrementing
<gonidelis[m]>
no?
<gonidelis[m]>
do you want me to implement the whole iter functionallity?
<K-ballo>
no, just advancing and dereferencing for a start
<gonidelis[m]>
functionality^^
<K-ballo>
your view isn't a view
<gonidelis[m]>
becuase of the copying
<gonidelis[m]>
i guess
<gonidelis[m]>
i should put a ton of refs
<K-ballo>
precisely
<K-ballo>
try it
<gonidelis[m]>
try it, as in try it and run it?
<K-ballo>
no, as in try to put a ton of refs and see what changes
<gonidelis[m]>
becaues this thing is far from compilable
<gonidelis[m]>
ok
<K-ballo>
it won't make a difference, but at least you'll get a clear understanding of why
<K-ballo>
for what it is worth, this op() thing is not something views have
<gonidelis[m]>
what is wrong with my iter class?
<K-ballo>
your iter class is mostly fine, it's just not implemented
<gonidelis[m]>
?
<gonidelis[m]>
i don't know what to do with my temp
<gonidelis[m]>
i put a ref and all of a suddent my view owns things
<K-ballo>
there's nothing you can possibly do with it
<gonidelis[m]>
i don't put a ref
<gonidelis[m]>
and it both owns and copies things
<gonidelis[m]>
https://wandbox.org/permlink/fvukZHxWAIJN7fpF I ref Rng and then my filter_view could easily take the `transform` result and chose whether to "filter" it or no. ahhhhhhhhh
<gonidelis[m]>
is the trick that I changed the contents of the range even if i didn't filter a given element?
<gonidelis[m]>
no i didn't
<gonidelis[m]>
it seems like this filter_view could do the seqeunce i suggested earlier
<gonidelis[m]>
so what was the point/
<gonidelis[m]>
?
<K-ballo>
again, op() isn't a view thing
<K-ballo>
a view is a range with O(1) copy
<K-ballo>
a range is something with begin/end
<K-ballo>
that's why the important stuff goes into the view's iterator ++ and *, which you don't have
<gonidelis[m]>
a right
<gonidelis[m]>
indeed
<gonidelis[m]>
i don't thing i will tame that beast today
<K-ballo>
that's the crux of the matter, the "filter operation" implementation is split into the iterator ++ and *