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/
nanmiao has joined #ste||ar
bita has quit [Ping timeout: 245 seconds]
nanmiao has quit [Quit: Connection closed]
K-ballo has quit [Quit: K-ballo]
jehelset has joined #ste||ar
hkaiser has quit [Quit: bye]
bita has joined #ste||ar
bita has quit [Ping timeout: 258 seconds]
shubham has joined #ste||ar
shubham has quit [Quit: Connection closed for inactivity]
K-ballo has joined #ste||ar
<sestro[m]>
Is there an approximate time frame for the release of 1.7.0 or does it depend on the issues assigned to the milestone?
<srinivasyadav227>
and try to provide some kind of similar implementation if possible
<hkaiser>
srinivasyadav227: uhh
<hkaiser>
sort is probably the worst candidate for vectorization as you need to look at each element separately in varying contexts
<hkaiser>
but I don't know anything about vectorization to begin with, so I'm not the right person to ask :/
<srinivasyadav227>
yea, true, but comparisons could help in speed up
<hkaiser>
absolutely
<hkaiser>
but sure, if vectorizing sort, the look at how to vectorize the sequential sorting of the leaf chunks - so you identified the correct spot
<srinivasyadav227>
yeas ;-)
<srinivasyadav227>
hkaiser: ok, if i could find any solution which could speed up, then can i add it to proposal ?
<hkaiser>
sure - you're free to add whatever you think you can handle ;-)
<srinivasyadav227>
ok cool ;-)
<hkaiser>
srinivasyadav227: in the case of 'sort' you could even rely on the standard library supplied version of sort: std::sort(std::unseq, ...) - if available
<hkaiser>
sort is unsequenced by design - iterations can not interfere with each other - so we should be (almost) fine to always call the unseq version from the standard if available
<hkaiser>
that needs more investigation, though
<srinivasyadav227>
hkaiser: i dont think standard supports that still, again i will try and look, i hardly find standard implementations for unseq, and msvc only supports std::par_unseq with for_each and gcc uses openmp for vectorization, will try and look in gcc implementation
<hkaiser>
srinivasyadav227: it does starting c++20, but I'm not sure if any std library has it implemented
<hkaiser>
that's why I said 'if available'
<srinivasyadav227>
hkaiser: oh damn, i am sorry! ;-)
<hkaiser>
don't be sorry - all is well
<srinivasyadav227>
hkaiser: thanks 🙃
<ms[m]1>
hkaiser: here now
<ms[m]1>
you wanted to discuss properties?
<hkaiser>
ms[m]1: yes
<hkaiser>
ms[m]1: I'm not sure I understand your prefer implementation
<hkaiser>
why do you allow prefer(...) and prefer(other_cpo, ...)?
<ms[m]1>
let's see if I remember what I did there...
<hkaiser>
ms[m]1: ok, I didn't see p2220 - will read
<ms[m]1>
but p1393 does it slightly differently anyway
<hkaiser>
yes
<hkaiser>
I'll go back to the drawing board then ;-)
<ms[m]1>
there it's possible to make is_preferable_v false, which means that one is only allowed to require a property (i.e. either one can apply the property or it's a compile error, as opposed to silently not applying the property)
<ms[m]1>
are the changes mostly a tag_invoke-ified propria/asio?
<hkaiser>
yah, mostly a rewrite of propria using CPOs
<hkaiser>
ms[m]1: so p2220 essentially turns properties themselves into CPOs
<ms[m]1>
sort of
<hkaiser>
so instead of having require/prefer/query they introduce a CPO for each property
<ms[m]1>
instead of require, there's a cpo for applying each property, which are tags as well
<ms[m]1>
right ;)
<hkaiser>
and prefer attempts to apply the property CPO or is an identity operation
<ms[m]1>
exactly
<hkaiser>
ok, so I can scratch my PR ;-)
<ms[m]1>
well... maybe for now, but I'm not convinced p2220 will be what gets accepted
<ms[m]1>
let's see though
<hkaiser>
I'm out of touch with the discussion, I admit
<ms[m]1>
me too tbh, I'm just guessing
<ms[m]1>
off to find whatever mailing list properties are discussed on...
<hkaiser>
most likely SG1
<hkaiser>
or LEWG - wash[m] might know
<diehlpk_work>
gdaiss[m], Was OCTOTIGER_WITH_GRIDDIM ported to kokkos?
<diehlpk_work>
If I try to increase the number the hydrolib does not compile
<ms[m]1>
hkaiser: I suppose the reason for having prefer be a cpo in p2220 is to emulate is_preferable_v = false with tag_invoke(prefer_t, property_t, ...) = delete
<ms[m]1>
and not really to customize prefer
<hkaiser>
ms[m]1: yah
<hkaiser>
I think I start to understand what you did with prefer
<hkaiser>
ms[m]1: even if I have to discard the PR, I think p2220 is the better solution
<ms[m]1>
it's at least simple, which I really like
<ms[m]1>
but tag_invoke (or something similar) would have to be standardized first
<hkaiser>
ms[m]1: something like tag_invoke _will_ be standardized - it's too useful
<hkaiser>
ms[m]1: there is also p2279
<ms[m]1>
yep, p2279 would be nicer
<ms[m]1>
tag_invoke is terrible for error messages
<hkaiser>
nod
<K-ballo>
yeah, hopefully not tag_invoke
<jbjnr>
I've just rebased 74 commits onto master from my parcelport branch. it took 3 days, and 67 commits are left (7 removed completely), of which about 55 had conflicts that I had to resolve by hand. But everything is now compiling (it won't actually work, but at least it's rebased). Total mess really. Should throw it all away and start from scratch.
<hkaiser>
jbjnr: I usually just combine all commits before rebasing
<jbjnr>
I considered that, but I didn't want to lose some of the separate strands of work that appear in different commits. The individual logs and diffs are useful when the branch is old and you forget what some of the bugs/problems were
<hkaiser>
K-ballo: it's still the best we have so far as a library solution
<K-ballo>
yes
shubham has joined #ste||ar
nanmiao has joined #ste||ar
<shubham>
Hello Nanmiao
<nanmiao>
Hi
bita has joined #ste||ar
nanmiao has quit [Quit: Connection closed]
<hkaiser>
shubham: FWIW, there is also P1243
nanmiao has joined #ste||ar
nanmiao has quit [Quit: Connection closed]
nanmiao has joined #ste||ar
shubham has quit [Quit: Connection closed for inactivity]
shubham has joined #ste||ar
<shubham>
@hkaiser: Okay I will check it out thank You 😊
nanmiao has quit [Quit: Connection closed]
nanmiao has joined #ste||ar
jehelset has quit [Ping timeout: 246 seconds]
nanmiao has quit [Quit: Connection closed]
shubham has quit [Quit: Connection closed for inactivity]