hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
diehlpk has joined #ste||ar
Yorlik__ has joined #ste||ar
Yorlik_ has quit [Ping timeout: 260 seconds]
diehlpk has quit [Quit: Leaving.]
K-ballo has quit [Quit: K-ballo]
diehlpk has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
diehlpk has left #ste||ar [#ste||ar]
hkaiser has quit [Quit: Bye!]
Yorlik__ is now known as Yorlik
aalekhn has joined #ste||ar
hkaiser has joined #ste||ar
K-ballo has joined #ste||ar
<Yorlik>
hkaiser: Thanks for that fix!
<hkaiser>
Yorlik: welcome
<hkaiser>
can we close the ticket?
<Yorlik>
I closed it already
<hkaiser>
perfect, thanks
<Yorlik>
If you have a momenbt for something completely different ...
<hkaiser>
sure
<Yorlik>
I want to implement a cluster-wide tagged search for components.
<hkaiser>
HPX components?
<Yorlik>
I think HPX has this broadcast in collections or so.
<hkaiser>
you can associate a name with every component and use this to locate it
<Yorlik>
Yes - I need to find them by any tag I assign them to
<Yorlik>
Oh! How would I do this?
<Yorlik>
This makes things easier in many cases.
<hkaiser>
the client API has register_as and connect_to functions
<Yorlik>
I guess I have like two similar, but different use cases here.
<Yorlik>
One is to find a singular special component, the other to find components that belong to a set (tag)
<Yorlik>
I have already implemented a basic struct for local search.
<Yorlik>
But I want to make this a cluster wide featrure.
<Yorlik>
That looks interesting. I'll check it out. Thank you!
<Yorlik>
hkaiser: How hard would it be to provide a lambda representing a conditional to narrow down the found id_types in the API you pointed me to before?
<Yorlik>
Or more general: Any callable ..
<Yorlik>
OFC - after having a list of id_types I could call a function on each of them. But that would generate a ton of inter-node traffic. Doing it directly on the node where the id_type lives could be done much more efficient.
<hkaiser>
Yorlik: you can use regular expressions for the names
<hkaiser>
at least simplified ones
<hkaiser>
gonidelis[m]: yt?
<gonidelis[m]>
Yes
<hkaiser>
see pm, pls
<hkaiser>
satacker[m]: hey, yt?
<satacker[m]>
hkaiser: yes
<hkaiser>
see pm, pls
aalekhn has quit [Quit: Connection closed for inactivity]
<Yorlik>
hkaiser: I was thinking of a lambda taking a local id_type as argument and allowing to query its data. that would for example allow spatial queries on subsets of components. A simple regex on the name can't do that.
aalekhn has joined #ste||ar
<hkaiser>
Yorlik: you can use the id_type of a local component instance and retrieve a pointer to it
<hkaiser>
hpx::get_ptr<>
<hkaiser>
but only for local instances
<hkaiser>
for remote instances you'd have to execute an action that retireves the data you need
<Yorlik>
probably it will come down to some per-node local searchers.
<hkaiser>
but you can create an action that takes an id_type and a function object (can't be a lambda as those are nott serializable, at least not in the general case) and have it invoke the function object on the locality where the instance lives
<Yorlik>
Yes. Probably I'd send a question to a searcher and let it execute a comnposable search and send the results back.
<hkaiser>
async<invoke_act>(colocated(id), f, args...);, where invoke_act is an action wrapping decltype(auto) invoke(id, f, args...) { return get_ptr(id)->f(args...); }
<Yorlik>
I'll probably just make a set of parametrized searchers that are executed by the search object.
<Yorlik>
I might even do it in Lua, with some C++ under the hood.
<Yorlik>
Since on the scripting side we will use object searches very often.
<Yorlik>
The good thing about the tagged search is, it's blazingly fast.
<Yorlik>
But it's not always sufficient
<Yorlik>
Tag based search and a general search solution are somewhat orthogonal.
aalekhn has quit [Quit: Connection closed for inactivity]