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/
<parsa>
hkaiser: i mean, i know these are caused by the refactoring going on. otherwise why would stuff in hpx::execution in execution_policy.hpp ask for stuff in hpx::parallel::execution which they can't access. i was hoping you'd know offhand
<hkaiser>
a lot of the stuff in hpx::parallel::execution has been moved to hpx::execution
<hkaiser>
parsa: are you sure you use a recent version of HPX?
<parsa>
it's release 1.6.0
<hkaiser>
ok
<hkaiser>
same problem with master?
<parsa>
i'm upgrading the octotiger base image. i can't just move to an untagged master otherwise we have to require it
<parsa>
i can try building on top of that fixing_datapar branch if it helps to check
<hkaiser>
ok, I'll bring it up with Mikael, but last time we spoke he said he'd like to give up doing the releases to somebody else
<parsa>
by any chance do you know what is the last release i can reasonably revert to?
<hkaiser>
no
<hkaiser>
try if the PR can be applied to 1.6 and make it part of the testing
<parsa>
hkaiser: follow up: with the fixing_datapar branch the previous errors are gone but new ones replaced them: https://pastebin.com/kkU7A1XQ
<hkaiser>
yah, this is after v1.6 stuff
<hkaiser>
so we need to create a patch for 1.6 that fixes this
nanmiao has joined #ste||ar
jehelset has joined #ste||ar
hkaiser has quit [Quit: bye]
K-ballo has quit [Quit: K-ballo]
bita has joined #ste||ar
bita has quit [Ping timeout: 245 seconds]
nanmiao has quit [Quit: Connection closed]
syrex has quit [Quit: syrex]
Gibbs has joined #ste||ar
Gibbs has quit [Quit: Connection closed]
Gibbs has joined #ste||ar
Gibbs has quit [Client Quit]
Coldblackice has joined #ste||ar
gdaiss[m] has quit [Quit: Bridge terminating on SIGTERM]
ms[m] has quit [Quit: Bridge terminating on SIGTERM]
rachitt_shah[m] has quit [Quit: Bridge terminating on SIGTERM]
jedi18[m] has quit [Quit: Bridge terminating on SIGTERM]
srinivasyadav227 has quit [Quit: Bridge terminating on SIGTERM]
bering[m] has quit [Quit: Bridge terminating on SIGTERM]
jbjnr has quit [Quit: Bridge terminating on SIGTERM]
klaus[m] has quit [Quit: Bridge terminating on SIGTERM]
RosheenNaeem[m] has quit [Quit: Bridge terminating on SIGTERM]
prahitha[m] has quit [Quit: Bridge terminating on SIGTERM]
HaimantikaMitra4 has quit [Quit: Bridge terminating on SIGTERM]
gnikunj[m] has quit [Quit: Bridge terminating on SIGTERM]
dashohoxha[m] has quit [Quit: Bridge terminating on SIGTERM]
rori has quit [Quit: Bridge terminating on SIGTERM]
gonidelis[m] has quit [Quit: Bridge terminating on SIGTERM]
pedro_barbosa[m] has quit [Quit: Bridge terminating on SIGTERM]
rainmaker6[m] has quit [Quit: Bridge terminating on SIGTERM]
mdiers[m] has quit [Quit: Bridge terminating on SIGTERM]
sestro[m] has quit [Quit: Bridge terminating on SIGTERM]
SagarB[m] has quit [Quit: Bridge terminating on SIGTERM]
AbanoubAsaad[m] has quit [Quit: Bridge terminating on SIGTERM]
k-ballo[m] has quit [Quit: Bridge terminating on SIGTERM]
CynthiaPeter[m] has quit [Quit: Bridge terminating on SIGTERM]
old_man[m] has quit [Quit: Bridge terminating on SIGTERM]
old_man[m] has joined #ste||ar
mdiers[m] has joined #ste||ar
rori has joined #ste||ar
rachitt_shah[m] has joined #ste||ar
gdaiss[m] has joined #ste||ar
gonidelis[m] has joined #ste||ar
k-ballo[m] has joined #ste||ar
jedi18[m] has joined #ste||ar
srinivasyadav227 has joined #ste||ar
bering[m] has joined #ste||ar
prahitha[m] has joined #ste||ar
ms[m] has joined #ste||ar
rainmaker6[m] has joined #ste||ar
jbjnr has joined #ste||ar
HaimantikaMitra[ has joined #ste||ar
dashohoxha[m] has joined #ste||ar
CynthiaPeter[m] has joined #ste||ar
klaus[m] has joined #ste||ar
gnikunj[m] has joined #ste||ar
RosheenNaeem[m] has joined #ste||ar
AbanoubAsaad[m] has joined #ste||ar
pedro_barbosa[m] has joined #ste||ar
sestro[m] has joined #ste||ar
heller1 has joined #ste||ar
SagarB[m] has joined #ste||ar
heller1 has quit [Client Quit]
jehelset has quit [Remote host closed the connection]
K-ballo has joined #ste||ar
shubham has joined #ste||ar
hkaiser has joined #ste||ar
<hkaiser>
srinivasyadav227: gcc 11.1 is out and it officially adds 'Experimental support for Data-Parallel Types (simd) from the Parallelism 2 TS'
<hkaiser>
ms[m]: yt?
<srinivasyadav227>
hkaiser: thats really nice ;-), i will check them out!,
<hkaiser>
ms[m]: the Octotiger people struggle with updating to use V1.6 because of its broken support for VC (see #5235) - if I created a patch against V1.6 - how much effort would it be to do a 1.6.1 release?
<hkaiser>
srinivasyadav227: cool - this could replace VC
<srinivasyadav227>
hkaiser: i am in verge of completing disentangling datapar, transform is completely done, and just need to adapt _ind for loop.hpp
<hkaiser>
nice!
<srinivasyadav227>
<hkaiser "ms: the Octotiger people struggl"> i fixed this in one my previous commit (PR to #5235 from PR #5298)
<hkaiser>
yah sure, but that PR is against master, not against V1.6
<hkaiser>
mass_density(mass_density > 0.0) = 7.0; assigns 7.0 to all elements of the vector register that are > 0
<hkaiser>
it's the vector equivalent of an if()
<hkaiser>
that syntax is available for the simd types as well, I believe
<srinivasyadav227>
mass_density is just simple double variable
<srinivasyadav227>
so is operator() doing something?
<hkaiser>
mass_density > 0.0 generates a mask which is then used by mass_density(mask) = 7.0;
<hkaiser>
so the assignment is applied only to the vector elements for which the mask is true
<K-ballo>
srinivasyadav227: mass_density can't be simply double
<srinivasyadav227>
oh yeas..i got it now..Vc changes internally it to vectors.. ;-)
bita has joined #ste||ar
<ms[m]>
hkaiser: yeah, making a patch release would be no problem at all, we should anyway go through prs/issues since 1.6.0 and see if there's something else that would be worth backporting to 1.6.1
diehlpk_work has quit [Remote host closed the connection]
diehlpk_work has joined #ste||ar
diehlpk_work has quit [Changing host]
diehlpk_work has joined #ste||ar
shubham has quit [Quit: Connection closed for inactivity]
Coldblackice_ has joined #ste||ar
Coldblackice has quit [Ping timeout: 240 seconds]
<hkaiser>
ms[m]: ok, I'll try to do that
<ms[m]>
hkaiser: ok, great
<ms[m]>
just reading through the logs, I think gregor has been using 1.5.0 with vc so that is likely the latest release with working vc
<hkaiser>
yes
<hkaiser>
see #5301, please add more
<ms[m]>
hkaiser: thanks, added some more
<ms[m]>
none are a must, but small enough that they could go in 1.6.1
<ms[m]>
tbh, it's not far from being worth a 1.7.0
<ms[m]>
I was thinking we should do one anyway soon, but not sure yet if there's something else that'd be worth waiting for (most likely not)
<hkaiser>
ms[m]: yah
<hkaiser>
I agree, might be easier just to do a full release
<srinivasyadav227>
approx. when is the next release?
<ms[m]>
I suppose the only thing we should wait for is 5235 in that case, since the vc stuff is what triggered the question about a patch release :P
<ms[m]>
srinivasyadav227: no timeline yet
<ms[m]>
we've aimed for a minor release roughly every six months, but we adjust to whatever is in flight at the moment
<hkaiser>
ms[m]: I agree
<srinivasyadav227>
ok ;-) , i will finish up Vc work in a day or 2 max
Gibbs has joined #ste||ar
<ms[m]>
ok, let's discuss in more detail tomorrow, but I think 1.7.0 sometime in may should be doable
<hkaiser>
nice
<ms[m]>
ci hasn't been broken for a change, so we don't really have any catching up to do
<ms[m]>
well, I should say it's only a tiny bit broken at the moment...
<srinivasyadav227>
i mean the else part, creating another function template and calling the CPO again
bita has joined #ste||ar
<K-ballo>
algorithms arent customization points
<srinivasyadav227>
K-ballo: sorry, can you please elaborate ;-)
<K-ballo>
I don't think I can
<K-ballo>
unless, CPO stands for customization point object
<srinivasyadav227>
yes, above i meant CPO as customization point object
bita has quit [Ping timeout: 250 seconds]
<srinivasyadav227>
my doubt was why are we doing #else part when HPX_COMPUTE_DEVICE_CODE is defined?, why cant we just rely on #if part
<hkaiser>
srinivasyadav227: the compiler complained about it, so I had to add the #else implementation
<hkaiser>
formally, the #if part is valid code and should work, but the compiler didn't like me
<srinivasyadav227>
yes #if part is working fine...no prob with it..was just curious about #else
<hkaiser>
it's a workaround for compilers that do not support the code
<srinivasyadav227>
okay ;)
V|r is now known as Vir
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
<jbjnr>
I'd like to use tag_invoke CPOs in the rma code, but it needs hpx_functional - which depends on serialization - but serialization depends on rma for special sending of rma types. Apart from splitting my stuff up, is there an easier way out?
<hkaiser>
jbjnr: keep your rms serialization code in the parcelport
<jbjnr>
(of the circular dependencies)
<hkaiser>
rma
<jbjnr>
there are rma chunks used by the serialization and rma traits and things in inut/output archive that "belong" in serialization in some sense
<hkaiser>
could you split the rma into serialization specific things and the actual rma?
<jbjnr>
my question was "Apart from splitting my stuff up, is there an easier way out?"
<hkaiser>
would need to see the code, but splitting things is usually one way of solving
<jbjnr>
(does the serialization really need hpx_functional - would it be possible to factor that out?)
<hkaiser>
don't know
<jbjnr>
Actually, I've got it backwards - hpx_functional depends on serialization
<hkaiser>
but all you need in serialization is some small rma structures that have no direct dependency on the actual rma
<jbjnr>
indeed, but it's a lot of work to redo it all
<hkaiser>
can I help?
<jbjnr>
not really I have been rearranging everythng to work around the modules and it's all a bit messed up
<jbjnr>
I thought creating an hpx_rma module was the solution, but now it turns out it isn't
<jbjnr>
well, it is, but I havve to rework the serializtion stuff
<jbjnr>
"but all you need in serialization is some small rma structures that have no direct dependency on the actual rma" - these structures are defined i the rma module, putting them somewhere else is somehow not right
<jbjnr>
looking at it more - I don't like that our CPOs are behind a serialization wall. It's wrong.
<jbjnr>
hpx_functional -> needs a separate -> hpx_serializable_function
<jbjnr>
just my $0.02
<hkaiser>
fair
<hkaiser>
in the end either everything depends on serialization (if the type specific serialization is in the same module as the type) or serialization will depend on everything else (if type serialization is in the serialization module)
<hkaiser>
we went with option 1)
nanmiao has quit [Quit: Connection closed]
jerrykakooza has joined #ste||ar
<jerrykakooza>
Hello, I am interested in participating in the GSoD
hkaiser_ has joined #ste||ar
jerrykakooza has quit [Quit: Connection closed]
hkaiser_ has quit [Ping timeout: 276 seconds]
hkaiser_ has joined #ste||ar
hkaiser_ has quit [Ping timeout: 276 seconds]
hkaiser_ has joined #ste||ar
hkaiser_ has quit [Ping timeout: 250 seconds]
<K-ballo>
I while ago I had proposed moving a bunch of these core pieces to a fundamentals module
<hkaiser>
which would be fine by me
<K-ballo>
I did most of the work, but I was appalled by all those file moves/renames
<K-ballo>
the benefits did not seem worth all the noise
<hkaiser>
it was difficult to get the right structure on first attempt