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/
diehlpk_work has quit [Remote host closed the connection]
diehlpk_work has joined #ste||ar
nanmiao11 has quit [Remote host closed the connection]
<weilewei> gnikunj[m] you need to register SC career fair before Oct 26: https://sc20.supercomputing.org/program/studentssc/job-fair/
<gnikunj[m]> weilewei thanks!
weilewei has quit [Remote host closed the connection]
rainybyte has quit [Quit: rainybyte]
hkaiser has quit [Quit: bye]
khuck has quit [Remote host closed the connection]
khuck has joined #ste||ar
khuck has quit [Ping timeout: 260 seconds]
shahrzad has quit [Quit: Leaving]
rainybyte has joined #ste||ar
khuck has joined #ste||ar
akheir has quit [Quit: Leaving]
khuck has quit [Ping timeout: 260 seconds]
rainybyte has quit [Quit: rainybyte]
khuck has joined #ste||ar
khuck has quit [Ping timeout: 240 seconds]
khuck has joined #ste||ar
khuck has quit [Ping timeout: 240 seconds]
klaus[m] has quit [Quit: killed]
mariella[m] has quit [Quit: killed]
bennie[m] has quit [Quit: killed]
teonnik has quit [Quit: killed]
kimbo[m] has quit [Quit: killed]
gdaiss[m] has quit [Quit: killed]
mdiers[m] has quit [Quit: killed]
wladimir[m] has quit [Quit: killed]
ms[m] has quit [Quit: killed]
dagmar[m]1 has quit [Quit: killed]
gonidelis[m] has quit [Quit: killed]
alexandros[m] has quit [Quit: killed]
louisa[m] has quit [Quit: killed]
k-ballo[m] has quit [Quit: killed]
rori has quit [Quit: killed]
kordejong has quit [Quit: killed]
heller1 has quit [Quit: killed]
gnikunj[m] has quit [Quit: killed]
tiagofg[m] has quit [Quit: killed]
parsa[m] has quit [Quit: killed]
rori has joined #ste||ar
gonidelis[m] has joined #ste||ar
dagmar[m]1 has joined #ste||ar
bennie[m] has joined #ste||ar
alexandros[m] has joined #ste||ar
louisa[m] has joined #ste||ar
klaus[m] has joined #ste||ar
kimbo[m] has joined #ste||ar
mariella[m] has joined #ste||ar
k-ballo[m] has joined #ste||ar
teonnik has joined #ste||ar
gnikunj[m] has joined #ste||ar
heller1 has joined #ste||ar
kordejong has joined #ste||ar
wladimir[m] has joined #ste||ar
gdaiss[m] has joined #ste||ar
ms[m] has joined #ste||ar
tiagofg[m] has joined #ste||ar
mdiers[m] has joined #ste||ar
parsa[m] has joined #ste||ar
mdiers[m] has quit [*.net *.split]
rori has quit [*.net *.split]
alexandros[m] has quit [*.net *.split]
teonnik has quit [*.net *.split]
tarzeau has quit [*.net *.split]
rori has joined #ste||ar
teonnik has joined #ste||ar
alexandros[m] has joined #ste||ar
mdiers[m] has joined #ste||ar
tarzeau has joined #ste||ar
mdiers[m] has quit [Changing host]
mdiers[m] has joined #ste||ar
khuck has joined #ste||ar
khuck has quit [Ping timeout: 244 seconds]
hkaiser has joined #ste||ar
khuck has joined #ste||ar
akheir has joined #ste||ar
weilewei has joined #ste||ar
khuck has quit [Ping timeout: 240 seconds]
rainybyte has joined #ste||ar
jbjnr has joined #ste||ar
<jbjnr> hkaiser, what does transfer_continuation_action do?
<hkaiser> the same as transfer_action except that it handles the continuation as well (e.g. sending back the result)
<hkaiser> actions themselves are empty (placeholder) types, cheap to instantiate, while the corresponding transfer_actions do the heavy lifting
<jbjnr> thanks
<jbjnr> still rying to locate the problem in the serialization
<heller1> what's the issue?
<jbjnr> stepping though the transfer action code etc and wondering why it is here!
<hkaiser> jbjnr: please try with #5004 if this solves your issue
<heller1> hkaiser: that would be nasty. How did it ever work?
<hkaiser> ahh, it's merged now, so try with master
<hkaiser> heller1: we made some changes just recently that broke at least msvc
<hkaiser> not sure if it broke gcc/clang as well
khuck has joined #ste||ar
<heller1> I see
<heller1> yeah, this code is nasty
khuck has quit [Ping timeout: 240 seconds]
<jbjnr> heller1, your objections to the whole parcelport nonsense are quite valid - but you could wrap something like gRPC (for example), in some awaitable stuff that integrated with hpx futures. The whole serialization and action handling would be replaced in one go with an external library of that kind - would only really need id types to be properly massaged I suspect.
<hkaiser> jbjnr: guys, let's not spill the baby with the bathwater
<heller1> jbjnr: yes
<heller1> but at the end of the day, you don't want to lose AGAS
<heller1> because that's where the real power comes in
<jbjnr> that's what I mean by id types being masseged
<jbjnr> massaged^
<jbjnr> they would need extra code that the 3rd party library coul;n't handle out of the box
<jbjnr> bbiab
<heller1> at the end of the day, a parcelport is just a remote executor of an action ;)
<hkaiser> yes
<hkaiser> lifting things out of a parcelport has the advantage of adding more flexibility but also the disadvantage of losing AGAS and putting the burden of serialization and scheduler integration onto the user - pick your poisong
<heller1> since AGAS is build on actions, I don't think so.
<heller1> I agree on serialization and scheduler integration
khuck has joined #ste||ar
<heller1> which might not be a bad thing
<hkaiser> well, that's an implementation detail, isn't it?
<heller1> depends on where you stand
<hkaiser> I mean AGAS being built on actions
<heller1> currently: yes
<heller1> ah
<heller1> it is an implementation detail indeed
<heller1> but an important one
<hkaiser> not for the user
<hkaiser> for us, yes
<heller1> no, but for HPX maintainability
<heller1> right
<heller1> all I am saying, if we stick to the AGAS example, instead of having the dependency on the global parcelport, spell it out as an explicit executor or something
<hkaiser> absolutely!
<heller1> and this will be a massive gain
<hkaiser> but I'm against spilling everything just because of some additional implementation burden
khuck has quit [Ping timeout: 240 seconds]
<heller1> sure
<jbjnr> I am very much in favour of making the parcelport into a an executor type
<jbjnr> I merged master and got a ton of conflicts again
<jbjnr> really fed up with all this
<hkaiser> jbjnr: sure, but first we should get things working before diving into yet another rabit hole
<jbjnr> I'm only trying to fix the existin code at the moment
<jbjnr> just pondering the future
<hkaiser> the reason for you issues is that you work off long living branches instead of trying to make small changes at a time
<diehlpk_work> jbjnr, Octo-Tiger meeting?
khuck has joined #ste||ar
<jbjnr> hkaiser, sometimes small changes are not enough
<jbjnr> diehlpk_work, did I miss the meeting?
<jbjnr> Apologies - Things are a bit hectic here and I can't completely control my time/duties
jbjnr_ has joined #ste||ar
jbjnr has quit [Ping timeout: 240 seconds]
jbjnr_ has quit [Remote host closed the connection]
weilewei has quit [Remote host closed the connection]
weilewei has joined #ste||ar
jbjnr has joined #ste||ar
<jbjnr> hkaiser, still trying to fix my code to get rid of all the linker errors for print stuff after your changes
jbjnr_ has joined #ste||ar
jbjnr has quit [Ping timeout: 240 seconds]
weilewei has quit [Remote host closed the connection]
jbjnr__ has joined #ste||ar
jbjnr_ has quit [Ping timeout: 258 seconds]
<gonidelis[m]> what is under /libs/full?
<hkaiser> jbjnr__: those are most likely caused by missing specialization for the types you use
<hkaiser> similar for the other functions
<K-ballo> we should look into transitioning the debugging print stuff to fmt
rainybyte has quit [Remote host closed the connection]
rainybyte has joined #ste||ar
<gonidelis[m]> `git mergetool` 0.0 now that's a tool
<gonidelis[m]> wow
rainybyte has left #ste||ar [#ste||ar]
<gonidelis[m]> since this commit is very very conflicted with master
<gonidelis[m]> Do you think that it is fissible to overcome those conflicts? Or should I just do the job in a new PR based on the current master?
<K-ballo> no need for a new PR, even if you choose to go and manually re apply all changes
<gonidelis[m]> y?
<K-ballo> what is it "very very" conflicted?
<gonidelis[m]> like a lot
<K-ballo> what is?
<gonidelis[m]> you mean what's the conflict?
<K-ballo> yes
<gonidelis[m]> but when I rebase it's like ok until it reaches
<gonidelis[m]> `libs/full/segmented_algorithms/include/hpx/parallel/segmented_algorithms/transform.hpp`
<K-ballo> that looks far from "very very"
<K-ballo> seems none of the files in question moved?
<gonidelis[m]> where do you see that?
<gonidelis[m]> that nothing moved I mena
<gonidelis[m]> mean^^
<K-ballo> no files added/removed
<K-ballo> you must have been lucky so far
<gonidelis[m]> the probelm is that there are seperate writes in the same files i think
<K-ballo> yeah, but that's conflicts from the basic kind
<gonidelis[m]> cool
<K-ballo> not even worth one "very", let alone two :P
<gonidelis[m]> lol
<K-ballo> if you create a new branch, cherry-pick commits one by one, and fix conflicts as you go
<K-ballo> that's no different than doing an interactive rebase
<K-ballo> you can then rename the new branch and the end result is the same
<gonidelis[m]> so you propose interactive rebase
<K-ballo> whatever works for you, they all result in the PR being updated
<K-ballo> is this the first time you've hit conflicts while rebasing?
<gonidelis[m]> ok but the main prerequisite is for me to know what code of mikel's I should pick over mine. right?
<K-ballo> more likely neither code will be right, you'll have to come up with new code that integrates both changes
<gonidelis[m]> shit great
<K-ballo> that's what a conflict is
<K-ballo> I'm starting to suspect you have never seen one before
<K-ballo> you must have been very very lucky
<gonidelis[m]> I worked on one or two during the summer
<gonidelis[m]> any idea why when I open the files with vscode mid-rebase it doesn't show the incoming changes?
<gonidelis[m]> negative...
<gonidelis[m]> my fault
<K-ballo> reduce_by_key unit test doesn't compile on msvc, hkaiser does it work for you?
<hkaiser> K-ballo: last time I checked it did work
<hkaiser> 4 weeks ago?
<K-ballo> odd, the failing code isn't exactly new
<hkaiser> I'll have a look
<hkaiser> K-ballo: yep, fails for me as well
<hkaiser> K-ballo: that's being caused by moving tuple to namespace hpx
<K-ballo> was tuple's detail also moved to namespace hpx? hpx::detail?
<hkaiser> apparently
<K-ballo> may be worth considering tuple_detail, will have a look eventually
<K-ballo> gonidelis[m]: you'll be removing all or most of tuple<> usage from parallel algorithms, right?
<hkaiser> I think msvc is hypocritical here
<K-ballo> no, the using namespace does that
<K-ballo> hpx namespace is the common ancestor
<hkaiser> why doesn't it fail for any of the others then?
<gonidelis[m]> K-ballo: yup
<K-ballo> different #includes ?
<hkaiser> reduce_by_key doesn't fail on any of the CIs
<K-ballo> different #includes
<K-ballo> it's the easiest explanation, without actually looking at it
<hkaiser> I don't think there is any using namespace involved
<K-ballo> what's the error you are getting?
<hkaiser> culd be that there is a namespace util { using hpx::tuple; }, though - for compatibility
<hkaiser> error C2872: 'detail': ambiguous symbol
<hkaiser> anyways, easy enough to fix
<K-ballo> we need to de-tuple code
<gonidelis[m]> we are doing this already i think
<gonidelis[m]> but why do you say that?
<K-ballo> bloat
<gonidelis[m]> what?
<K-ballo> tuple is super bloatty
<gonidelis[m]> cool
<K-ballo> any fixed size outside of interfaces is gratuituos
<gonidelis[m]> aggree
<K-ballo> *any fixed size use
<K-ballo> and any use in interfaces is.. a rather poor interface
<gonidelis[m]> what do you mean by 'interfaces' ?
<K-ballo> user facing entities, documented functions, that kind of stuff
<K-ballo> stuff users would (rightfully) call/use
<gonidelis[m]> oh ok I see
<gonidelis[m]> and what do you mean 'any fixed size' ?
<K-ballo> fixed number of tuple elements
<K-ballo> mostly tuple<A, B, C> vs tuple<Pack...>
<gonidelis[m]> so in_out_result isn't fixed?
<K-ballo> doesn't in_out_result have 2 elements? in and out?
<gonidelis[m]> that's fixed
<gonidelis[m]> yes^^
<gonidelis[m]> i `git fetch`ed `upstream master` and then like `git rebase i` and re-did like every commit. For some reason, mikel's commits were not visible though....
<gonidelis[m]> it was just my commits. they came like conflicts and vscode was asking me whether I wanted to accept my own changes through the PR
<gonidelis[m]> ahhh.. the conflicts are not on github anymore though....
<gonidelis[m]> I am confused....
<gonidelis[m]> So what's the difference between full, core and parallelism?
jbjnr__ has quit [Ping timeout: 264 seconds]
<gonidelis[m]> hkaiser: I started working again on the PRs
<gonidelis[m]> I know you are tied up. Don't worry... I will keep working and you can comment on, whenever you can
<gonidelis[m]> ;)
<hkaiser> ok, thanks
<gonidelis[m]> i think that in case i fix those tests the PR should be ready
<hkaiser> nice
<gonidelis[m]> ok we will talk. Need to go now. It's pretty late. Bye B)