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 joined #ste||ar
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
diehlpk_work has quit [Remote host closed the connection]
nanmiao has quit [Quit: Connection closed]
itn has joined #ste||ar
itn has quit [Quit: Connection closed]
zao has quit [Ping timeout: 248 seconds]
zao has joined #ste||ar
mi1998[m] has quit [Ping timeout: 248 seconds]
mi1998[m] has joined #ste||ar
<zao>
There's someone on Slack in #hpx talking about GSoC by the way, if people haven't noticed.
itn has joined #ste||ar
<itn>
Greetings of the day,
<itn>
An idea to share that to implement shift_left && shift_right algorithms I've created a PR #5278 consisting of a very rough idea based on exemplar (sequential) implementation provided in issue #3706
<itn>
Please share your suggestions, ideas, guidance regarding the same as I am intent ending to become a part of GSoC'21 for the same project.
<itn>
Regards
itn[m] has joined #ste||ar
<zao>
Hey!
<zao>
Saw your message on Slack, I'm happy that you found your way here.
<zao>
(I have nothing to do with GSoC and very little to do with HPX, but wanted to welcome you anyway)
<itn>
Nice to meet you zao
<itn>
I am glad to be a part of this org. Thank you so much for the warm welcome. I look forward to know each one of you and at the same time contribute to the org in all my abilities.
itn has quit [Quit: Connection closed]
itn has joined #ste||ar
itn_ has joined #ste||ar
itn has quit [Client Quit]
itn_ has quit [Client Quit]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
<gonidelis[m]>
hkaiser: should i remove the `is_seq`s inside the tag_fallback_invoke implementations and adopt `cal()` as well?
<hkaiser>
yah sure - if possible
<hkaiser>
either use is_seq and call2() or remove it
<gonidelis[m]>
nah, let's keep it clear
<gnikunj[m]>
hkaiser: hi!
<gonidelis[m]>
i don't want to panish future contirbutors
<hkaiser>
hey gnikunj[m]
<hkaiser>
woul 11 work for you today?
<gnikunj[m]>
absolutely
<hkaiser>
11am CDT that is
<hkaiser>
cool
<hkaiser>
thanks
<gnikunj[m]>
apologies that I didn't update you before. Been working on C++Now presentation and then my mid terms came in :/
<hkaiser>
no worries
<gonidelis[m]>
we may saved the daylights but for sure we did not save our friend's nikunj schedule
<gnikunj[m]>
short update: I've kind of implemented a hack that ensures all future gets ready so things are working as of now. Need to still think about the timers for artificial benchmarks.
<gnikunj[m]>
<gonidelis[m] "we may saved the daylights but f"> Let's talk about that in the meeting ;-) I'll adjust as much as I can.
<gnikunj[m]>
sometimes things just don't work though :/
<gonidelis[m]>
so you are in for today?
<gnikunj[m]>
yes yes. I cancelled all plans :P
<gonidelis[m]>
that's what i call commitment
<gonidelis[m]>
see you there ;)
<gnikunj[m]>
see you ;-)
<gonidelis[m]>
K-ballo: yt?
nanmiao has joined #ste||ar
<K-ballo>
gonidelis[m]: partially
<gonidelis[m]>
K-ballo: i don't want more than just a part of you
<gonidelis[m]>
see pm please
<K-ballo>
in that case it'll take a while
<gonidelis[m]>
K-ballo: should i expect a response within the day?
<K-ballo>
probably late today, hopefully
<gonidelis[m]>
fingers-crossed
<jbjnr>
anyone there?
<srinivasyadav227>
yes
<jbjnr>
I do not know you srinivasyadav227
<jbjnr>
are you new?
<jbjnr>
(to hx I mean)
<jbjnr>
* (to hpx I mean)
<srinivasyadav227>
yes, i am new, 2 months may be ;-)
<jbjnr>
ok.
<jbjnr>
I will ask a question that you or maybe hkaiser or K-ballo or ms can answer if they check in later .... I have an allocator, templated on the type T, but also templated on a parcelport type (say libfabric, mpi, tcp, other), I need the user to be able to create the right allocator, without knowing which parcelport they are using. They just want an object X, but I must give them an object X`<parcelport type>. I can provide the
<jbjnr>
right virtual interface for this so that they get a base class object and the instantiated one can be overridden by the right type, but there might be multiple parcelports compiled into hpx ... I can also provide an abstraction that the user gets the allocator from the 'active' parcelport - but I wonder - do we already have anything like this inside hpx where we do something similar? I don't want to over-engineer the solution
<jbjnr>
when there might be a simpler way I didn't think of ...
<jbjnr>
Usse case - the user might want an hpx::channel<Thing> - but I need to make sure that under the hood, they are actually using an hpx:::channel<Thing, libfabric> - but they might have compiled MPI in as well - if only one parcelport is compiled it, things are very straightforward ....
<jbjnr>
* Ue case - the user might want an hpx::channel<Thing> - but I need to make sure that under the hood, they are actually using an hpx:::channel<Thing, libfabric> - but they might have compiled MPI in as well - if only one parcelport is compiled it, things are very straightforward ....
<jbjnr>
* Use case - the user might want an hpx::channel<Thing> - but I need to make sure that under the hood, they are actually using an hpx:::channel<Thing, libfabric> - but they might have compiled MPI in as well - if only one parcelport is compiled it, things are very straightforward ....
diehlpk_work has joined #ste||ar
<gnikunj[m]>
jbjnr: why not have a default case and then have user use hpx::channel<Thing, libfabric> when the user doesn't want to use default case? You can have a cmake flag that sets default libfabric and then have a type alias for it.
<gnikunj[m]>
fixes the need of adding extra steps and clears the clutter as well imo
<hkaiser>
jbjnr: I don't think we should specialize channel for the parcelport
<gnikunj[m]>
hkaiser: meeting?
<hkaiser>
yes, I sent an email
<jbjnr>
It's actually s apecialization of the memory behind the channel, not the channel itself.
<jbjnr>
I didn't explain quite as well as I thought
<jbjnr>
specialization of the memory behind the <thing> that you send over the channnel
<jbjnr>
I have an implementation, but I know that when I put in a PR you will complain, so I might as well ask beforehand.
<hkaiser>
can't we derive the allocator from the current parcelport used?
<jbjnr>
That's what my current implementation does
<jbjnr>
I use a get current/active parcelport to supply an allocator
<jbjnr>
I will need to make some changes to the channel though since parcelports do/don't support rma operations etc etc
shubham has joined #ste||ar
<hkaiser>
jbjnr: essentially we need a new API on the parcelports that abstracts away the specifics
<hkaiser>
like rdma_put(locality, ptr, size, remote_ptr) and rdma_get(locality, remote_ptr, ptr, size) or similar
<srinivasyadav227>
if yes, what should be done before working on #2333?, i think now i have good understanding of vc
<hkaiser>
srinivasyadav227: well, #2333 lists what's still not done
<hkaiser>
so yes
<hkaiser>
I thought we talked about this
<srinivasyadav227>
hkaiser: is this correct flow? 1. fixing up remaining compilation problems related to vc 2. seperate existing 3. test for datapar performance 4. implement #2333
<srinivasyadav227>
hkaiser: yes, i was confused with the workflow
<hkaiser>
nod, I doubt however that you can do all algorithms over this summer
<srinivasyadav227>
hkaiser: you mean datapar #2333?
<hkaiser>
yes
<hkaiser>
as said before, I'd suggest you rather under-promise but over-deliver instead of the opposite
<hkaiser>
srinivasyadav227: the purpose of the proposal is for you to figure out a) what you would like to do and b) lay out a concrete timeline of things you believe are required to achieve this
<hkaiser>
the projects we describe can only layout the scope of what we believe would be viable tasks
<jbjnr>
hkaiser: did that LCI Lady Elizabeth show any more interest in the task bench project
<hkaiser>
in the end your task is to figure all of this out dependening on a) your interestes and b) your self-assessment to define a timeline
<hkaiser>
jbjnr: I have not heard anyting from her, unfortunately
<jbjnr>
And yes to the parcelport put(...) etc. I will continue with my existing solution since it fits with your suggestion. I secretly hoped you'd suggest something better.
<jbjnr>
I'll ping her and see if she's interested
<hkaiser>
jbjnr: I don't have anything better, ATM
<srinivasyadav227>
hkaiser: my plan was to adapt as many algorithms to datapar by community bonding period, then switch to par_unseq (GSoC project), then after GSoC continue the work on datapar
<hkaiser>
ok, sounds good
<srinivasyadav227>
hkaiser: ;)
nanmiao has quit [Quit: Connection closed]
nanmiao has joined #ste||ar
shubham has quit [Quit: Connection closed for inactivity]