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
diehlpk_work has quit [Remote host closed the connection]
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
<ms[m]> gonidelis[m]: all our policies support the task tag
<gonidelis[m]> ms[m]: thanks
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
<K-ballo> there's some HPX specific flag to set instead of CMAKE_CXX_STANDARD
<K-ballo> (not ideal, but it's what it is)
<hkaiser> ms[m]: hey, I could use a pair of eyes looking at the task_group implementation
<hkaiser> there is apparently a race somewhere which I can't spot, no idea what's wrong :/
<srinivasyadav227> K-ballo: it configured with `-DHPX_WITH_CXX20=On` thanks! ;)
<hkaiser> K-ballo: you said you started to work on the fundamentals module
<K-ballo> and stopped too
<ms[m]> hkaiser: ok, I'll try to have a look
<ms[m]> anything in particular that you think might be the cause of the race?
<hkaiser> is that available somewhere, I think this would be a better option than what John suggested with the serializable function module
<hkaiser> ms[m]: from the tests I surmise that the wait() does not always actually waits :/ I can't figure it out why - everything looks kosher to me
<hkaiser> K-ballo: mind if I take that on?
<K-ballo> sure, I'm not planning to
<hkaiser> ok
<ms[m]> hrm, ok
<K-ballo> there was a corresponding ticket
<ms[m]> does it reproduce for you?
<hkaiser> ms[m]: no
<hkaiser> happens on some of the builders, but there it's consistent, I believe
<ms[m]> all right, I'll see what I can find out
<hkaiser> K-ballo: nod
<hkaiser> ms[m]: thanks a lot! has to be something glaringly obvious - it probably stares me right in the face
<hkaiser> ms[m]: it has to be something related to the latch implementation as the task_group doesn't do anything sophisticated anyway
<srinivasyadav227> hkaiser: replacing Vc means overwriting the new implementation(with gcc std-simd) on existing Vc datapar or writing new implementation keeping Vc datapar separately?
nanmiao has quit [Ping timeout: 240 seconds]
diehlpk_work has joined #ste||ar
<diehlpk_work> hkaiser, gnikunj[m] gonidelis[m] Hey, could you please click the like to mentor button on the GSoC project ou are interested in?
<gonidelis[m]> i think i did
<gonidelis[m]> didn't i?
<diehlpk_work> gonidelis[m], No, you did not
<diehlpk_work> At least the webpage does not show you as the mentor
nanmiao has joined #ste||ar
<gnikunj[m]> <diehlpk_work "hkaiser, gnikunj gonidelis[m] He"> sure, I'll do it tonight
<hkaiser> srinivasyadav227: I'd keep Vc separated for now
<hkaiser> diehlpk_work: will do
<srinivasyadav227> hkaiser: ok
<hkaiser> I think we should create the gcc simd traits in a separate directory adjacent to the Vc traits
<srinivasyadav227> yes, i was planning for that
<srinivasyadav227> hkaiser: there are couple of fixes before that related to hpx building with c++20, if i can solve them can i create a seperate PR for that?
<hkaiser> I'd appreciated if you did
<gonidelis[m]> <diehlpk_work "At least the webpage does not sh"> ok i will
<hkaiser> diehlpk_work: done now
<srinivasyadav227> hkaiser: cool
nanmiao has quit [Ping timeout: 240 seconds]
<hkaiser> gonidelis[m]: see pm pls
nanmiao has joined #ste||ar
<ms[m]> hkaiser: I think the latch is fine
<ms[m]> something is up with the argument handling in run, but I can't tell what
<ms[m]> it's only the second test that fails, with n - 1 and n - 2 being passed as parameters, not captured
<hkaiser> ms[m]: don't think so
<hkaiser> ahh no!
<hkaiser> you're right - I'm an idiot
<hkaiser> I was looking at the wrong spot (as usual)
<gnikunj[m]> hkaiser: gonidelis[m] : we did it \o/
<hkaiser> \o/
<gonidelis[m]> :DDDD
<hkaiser> how did it go
<gnikunj[m]> it went well. There were people thanking me in the end ;_;
<gnikunj[m]> I'm so glad I didn't **** it up :D
<hkaiser> gnikunj[m]: glad everything worked out
<jedi18[m]> Are we talking about the C++ Now talks? Congratulations!
<jedi18[m]> Will the videos be put up on youtube?
<gonidelis[m]> jedi18: yes! ;)
<gonidelis[m]> thanks
<jedi18[m]> Oh nice, look forward to watching them once they're uploaded
<hkaiser> ms[m]: many thanks for your time, I think I found the issue - thanks to you
<ms[m]> hkaiser: \o/
<ms[m]> what was it?
nanmiao70 has joined #ste||ar
nanmiao70 has quit [Client Quit]
nanmiao34 has joined #ste||ar
nanmiao34 has quit [Client Quit]
nanmiao87 has joined #ste||ar
nanmiao87 has quit [Client Quit]
nanmiao has quit [Ping timeout: 240 seconds]
nanmiao has joined #ste||ar
<hkaiser> ms[m]: the arguments should be moved to the capture using make_tuple, not forward_as_tuple
<ms[m]> hkaiser: ah, I was wondering about that one
<ms[m]> What is the use case for forward_as_tuple?
<K-ballo> forwarding..
<K-ballo> it's the tuple<Ts&&..> equivalent to fun(Ts&&...)
<hkaiser> ms[m]: the arguments where captured as references which made them invalid at the point of actually running the lambda
<hkaiser> classic beginner's mistake :/
nanmiao has quit [Quit: Connection closed]
nanmiao has joined #ste||ar