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>
hkaiser: what's with those quarantine reports on the fellows mailing list
<hkaiser>
K-ballo: just ignore them
<K-ballo>
they are actual actual spam
<K-ballo>
they make little sense
<hkaiser>
I asked for this list to have a spam filter because we received a lot of spam, now we get the report :/
<K-ballo>
ooh, not *that* quarantine
<hkaiser>
;-)
<hkaiser>
I have not figured how we can add mails to the blacklist
<gonidelis[m]>
K-ballo: can i use ranges algorithms with the pipe operator?
<gonidelis[m]>
or does it only work for views?
<hkaiser>
gonidelis[m]: works only for views or adaptors
<gonidelis[m]>
hkaiser: hm ok
<hkaiser>
at least the operator|() provided by range-v3 works only for those
<gonidelis[m]>
i see that the algorithms cases were it actually mattered to have a view counterpart, there is
shubham has joined #ste||ar
<hkaiser>
gonidelis[m]: right
<gonidelis[m]>
hkaiser: hm thanks
<jedi18[m]>
Hi! Sorry I haven't been active over the past two weeks, I had my end sems. They're almost done (just practicals left) so I'll begin contributing soon
<hkaiser>
jedi18[m]: cool, no worries, and thanks!
<srinivasyadav227>
i have coulpe of queries regarding std-simd
<hkaiser>
I'll have to leave soon, but please ask away
<jedi18[m]>
hkaiser: Thanks :)
<srinivasyadav227>
for both Vc(datapar) and std-simd), if we want to implement algorihtms which take function as argument like for_each, transform etc... the function object or function should be a function template or but not acutal function right?, then only we can vectorize?
<hkaiser>
the function/function object has to be callable both, with the plain (underlying) type and the vector-type (which might be different for different architectures), so yes, a template would work best
<srinivasyadav227>
so user should be aware of giving function template to algorithms rather than normal function when using data par / simd policy
<hkaiser>
absolutely
<hkaiser>
the user should also be aware that the type used to invoke the function (object) might be a vector-type and the always th eunderlying type used to invoke the algorithm
<hkaiser>
so the body of this function has to be written in generic terms such that it will compile for all possible types passed in
<hkaiser>
correction: the function may be invoked with vector-types of different width, not with the underlying type
<srinivasyadav227>
ok cool, got it thanks, now its clear ;), i just started working on std-simd (gcc) today.. one more last question please ;) now required traits for std-simd should be impl then this (https://github.com/STEllAR-GROUP/hpx/issues/2333) should be done replacing the Vc(datapar) right?
<hkaiser>
yes
<hkaiser>
we left Vc in to keep at least one implementation of the traits
<hkaiser>
in the past we mplemented the traits for other libraries, but all of that has already been removed
<hkaiser>
ok, gotta go now - sorry
<srinivasyadav227>
cool, thanks np ;)
hkaiser has quit [Quit: bye]
shubham has quit [Quit: Connection closed for inactivity]