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/
hkaiser has quit [Quit: bye]
diehlpk_work has quit [Ping timeout: 258 seconds]
jbjnr has quit [Quit: Idle for 30+ days]
<rachitt_shah[m]>
gnikunj: are you available on monday/tuesday for a call on APIs?
<rachitt_shah[m]>
Wanted some direction before starting out
<srinivasyadav227>
hkaiser: gnikunj Hi, could please look at this https://github.com/STEllAR-GROUP/hpx/pull/5328, here `clang-newest` and `clang-apex` checks were failing because std-simd was partially implemented for clang compilers, so would you recommend enabling std-simd to work only with GCC for now and enable it for clang later when std-simd is implemented completely? please let me know any if you have any other suggestions,
<srinivasyadav227>
thank you :)
<hkaiser>
srinivasyadav227: I left some comments on that PR - I think that the whole PR can be simplified a lot
rachitt_shah[m] has joined #ste||ar
<rachitt_shah[m]>
<gnikunj[m] "rachitt_shah sure, Monday someti"> Evening works for you? I'll send in invite for 7:00 - 7:30 PM IST?
<srinivasyadav227>
hkaiser: yes, i have looked into comment on projections part, i have been working on it :)
<hkaiser>
srinivasyadav227: it's not just the projections
<hkaiser>
I think there is no need to duplicate all the code used for the datapar vectorization
<hkaiser>
all that's needed is to implement the four traits for experimental::simd, rest rest should (hopefully) stay untouched
<srinivasyadav227>
hkaiser: okay, then the naming convention should be datapar only instead of simd? most of the duplication happened because of renaming of datapar to simd
<hkaiser>
hmm
<hkaiser>
does the naming of the internally used datastructures/functions matter?
<hkaiser>
if yes - sure rename those, but do it for Vc as well
<hkaiser>
the only thing visible to the user that would be renamed is the execution policy
<hkaiser>
or is ther emore?
DeepakS[m] has joined #ste||ar
<srinivasyadav227>
yes ,only execution policy name is visible to user
DeepakS[m] is now known as Deepak1411[m]
<gnikunj[m]>
rachitt_shah: yes, 7PM works for me.
<gnikunj[m]>
srinivasyadav227: will do
<hkaiser>
srinivasyadav227: so why did you rename/duplicate all the inner functions - I might miss something here - please explain your rationale
<srinivasyadav227>
<hkaiser "does the naming of the internall"> yea, not really, functionally does not change, its just renaming, if datapar and vectorpack naming is okay for simd, then i would revert back and only ExPolicy would be simd would be renamed? is this okay?
<srinivasyadav227>
<hkaiser "srinivasyadav227: so why did you"> Vc internally was previously using datapar naming convention, and std simd uses simd as naming, so i thought it would be clean
<hkaiser>
srinivasyadav227: I'm fine with renaming the inner functions as well - but why the duplication?
<srinivasyadav227>
hkaiser: would Vc be removed later when std-simd is standardised? or both exist?
<hkaiser>
I think we would remove Vc (the four traits that are specialized for Vc types)
<hkaiser>
as a first step I believe all what's needed to support experimental::simd would be to create equivalent traits for it
<hkaiser>
the next step would be rename execution::datapar to execution::experimental::simd
<hkaiser>
then you can decide whether you want to rename the inner facilities from ...vectorpack... to something else
<srinivasyadav227>
oh okay, i get it now, sorry i was mistaken, i thought Vc would be completely removed with naming convention, thats why renaming caused lot of duplication for now
<srinivasyadav227>
i think, renaming only execution policy to simd and adapting 4 new traits for std-simd would be enough?
<hkaiser>
as a first step, definitely - then we'll see what's left
<srinivasyadav227>
hkaiser: okay, thank you :), i will to fix everything by tmrw