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]
diehlpk_work has quit [Remote host closed the connection]
geoboom has joined #ste||ar
bita has quit [Ping timeout: 258 seconds]
sivoais has joined #ste||ar
geoboom has quit [Quit: Connection closed]
jehelset has joined #ste||ar
geoboom has joined #ste||ar
hkaiser has joined #ste||ar
K-ballo has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
<gonidelis[m]>
K-ballo: yt?
<K-ballo>
gonidelis[m]: just ask, and I'll answer when I'm here
<gonidelis[m]>
`auto rng = vi | transform([](int i){return std::to_string(i);});`
<gonidelis[m]>
K-ballo: what's `rng`'s type?
jehelset has quit [Remote host closed the connection]
<gonidelis[m]>
hkaiser: yt?
<K-ballo>
if only standard operations are involved, some specialization of ranges::transform_view
<gonidelis[m]>
i miss your "if only" part?
<gonidelis[m]>
what standard ops?
<K-ballo>
the type of rng can be pretty much anything, depending on the type of vi and other contextual information not given
<K-ballo>
I'm assuming that everything that hasn't been specified in the question can't possibly affect the answer
<K-ballo>
I'm sure there's a trick, or you'd ask a compiler and not me
bita has joined #ste||ar
<gonidelis[m]>
no trick
<gonidelis[m]>
K-ballo: i just had a conversation with mikael today morning. assume `vi` being `std::vector<int>`
<gonidelis[m]>
then `rng` is of type `transform_view`
<gonidelis[m]>
and is not calculated at all at this step
<gonidelis[m]>
ms[m]: so it seems like you were right. it's not a std::vector<std::string>. it's a `transfrom_view` and thus it is actually lazy and not calculated at this step
<K-ballo>
the view can't possibly compute its contents, who would own those elements?
<K-ballo>
all standard range adaptor objects return some range view
<hkaiser>
gonidelis[m]: sorry for bailing out on you
<ms[m]>
gonidelis[m]: ok, right
<ms[m]>
then I suppose if there's to be any parallelism involved in evaluating those lazy views it would be for example in something like `to` (maybe others)?
<gonidelis[m]>
hkaiser: no problem at all
<gonidelis[m]>
ms[m]: why and how is `to` associated to laziness? i am missing sth here...
<K-ballo>
`to` and maybe others are "actions" in v3 terminology, afaik C++ doesn't have any yet
<K-ballo>
actions aren't lazy
<hkaiser>
passing a (chain of) ranges to a parallel algorithm does the trick as well
<ms[m]>
nothing specific about to (still just scratching the surface of the ranges terminology), but anything that forces the evaluation of a view is potentially a candidate for parallelization
<K-ballo>
that's tentatively being called "view materialization", but meh
<ms[m]>
let's go with "view materialization" for now then
<K-ballo>
should be container materialization, the view already exists
<K-ballo>
anyways
<ms[m]>
"a view is materialized into a container"? could go either way
<K-ballo>
it draws from temporary materialization, where a prvalue is materialized into an object
<K-ballo>
the (temporary) object is what's being materialized
<gonidelis[m]>
K-ballo: the temporary obj is the view in this case (not the range)? isn't it?
<K-ballo>
the view is the prvalue
<K-ballo>
fwiw views are ranges too
<gonidelis[m]>
wait a sec... what's `to` in range-v3? i am lost... i thought you were referring to the executors thing
<K-ballo>
executors have a `to` thing?
<hkaiser>
no
<gonidelis[m]>
...
<gonidelis[m]>
deja vu
<gonidelis[m]>
shit... i messed up with the `.on` thing
<gonidelis[m]>
what `to` are you reffering to?
<K-ballo>
the one from ranges-v3
<gonidelis[m]>
i don't have a clue about it? how do i google it?
<K-ballo>
point google to ranges-v3 github source?
<gonidelis[m]>
given that it's an english preposition idk if that would have any useful results
<K-ballo>
github's own search does
<K-ballo>
or you could always search for "ranges::to"
<gonidelis[m]>
ahhh i did search that, but then again maybe it was my fault for searching in the range-v3 docs
<gonidelis[m]>
i forgot niebler's opinion on docing stuff
diehlpk_work has joined #ste||ar
<gonidelis[m]>
<K-ballo "the (temporary) object is what's"> (i was dismantling the whole prvalue, xvalue, lvalue thing again just to get your last message on the topic) so, to consider this properly: the parallelization candidate appears on the materialization step, namely when a view is materialized into a container
<gonidelis[m]>
`auto rng = vi | transform([](int i){return std::to_string(i);});` is not such a case
<gonidelis[m]>
K-ballo: ^^
<K-ballo>
what would you parallelize in such an expression?
<gonidelis[m]>
`transform` ?
<K-ballo>
as in the creation of the view?
<gonidelis[m]>
yes
<gonidelis[m]>
or no
<gonidelis[m]>
you tell me
<K-ballo>
how would you go about parallelizing the creation of the transform view?
<gonidelis[m]>
that's what I and mikael are asking
<gonidelis[m]>
exactly(?)
<gonidelis[m]>
the suggestion is that we parallelization the materialization of the view
<gonidelis[m]>
into a range
<gonidelis[m]>
an actual object
<K-ballo>
a container, containers contain
<gonidelis[m]>
yy
<gonidelis[m]>
into a container
<gonidelis[m]>
the suggestion is that we paralleliz the materialization of the view into a container^^
<gonidelis[m]>
parallelize** goddamit
<K-ballo>
what other option is there?
<gonidelis[m]>
good
<gonidelis[m]>
we aggree on that
geoboom has quit [Ping timeout: 240 seconds]
<gonidelis[m]>
the actual question though is: when is this so called "materialization" taking place?
<gonidelis[m]>
is it when we actually use `rng` late on?
<gonidelis[m]>
isn't it?
bita has quit [Read error: Connection reset by peer]
<gonidelis[m]>
i know that i shouldn't but for some reason i am happier compared to when we were accepted for gsoc ;p
<ms[m]>
hkaiser, diehlpk_work (anyone else interested as well of course): could we set a short gsod meeting for early next week (tue or wed would be ideal) just to get slightly organized for gsod
<ms[m]>
we'd need to find a writer by may 17th
<diehlpk_work>
ms[m], Tue at 9 CDT?
<hkaiser>
Tue morning is bad for me
<hkaiser>
Thursday would work
<diehlpk_work>
would work for me as well
<gonidelis[m]>
ms[m]: count me in
<ms[m]>
Usual hpx meeting slot? Works as well
SagarB has joined #ste||ar
<diehlpk_work>
ms[m], Sure, if we do it right as the beginning, so I can leave after that
<ms[m]>
Alright, thanks! It's not officially the week for the hpx meeting anyway so we can keep it short
<hkaiser>
nod
<gonidelis[m]>
+1
<SagarB>
Hello Everyone! I am a technical writer interested to work with HPX this Season Of Docs! I have gone through the GitHub Page & read the project details. It fits with my interest of work. Can anyone help me get started?:)
<diehlpk_work>
SagarB, Welcome
<diehlpk_work>
ms[m], rori would be a good point of contact.
<SagarB>
Thanks diehlpk_work:)
<gnikunj[m]>
ms: I'll join in as well
<ms[m]>
SagarB: welcome! I can't unfortunately stay around to chat right now, but would you mind telling us a bit more about your background (either here or on the hpx-users/hpx-devel mailing lists)?
<ms[m]>
we might want to set up a call sometime next week to talk a bit more in detail as well
<ms[m]>
(possibly even on the aforementioned call... it's about gsod after all)
<SagarB>
Yup, sure ms[m], I'll be happy to share the details on the mailing list.