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
tufei__ has joined #ste||ar
tufei_ has quit [Remote host closed the connection]
K-ballo has quit [Quit: K-ballo]
Yorlik has joined #ste||ar
Yorlik has quit [Ping timeout: 245 seconds]
hkaiser has joined #ste||ar
<dkaratza[m]> ms: good morning! Is it possible to reschedule our meeting? Maybe do it tomorrow morning?
Yorlik has joined #ste||ar
<ms[m]> dkaratza: yep, works for me
<ms[m]> I suppose gonidelis might not like the morning, but for us in europe that should work fine
<hkaiser> ms[m], dkaratza[m]: toorrow I will not be able to join for sure - today would have worked...
<hkaiser> but np, please meet without me
<ms[m]> hkaiser: 👍️
<hkaiser> ms[m]: I'll join the PMC call later today, however
<ms[m]> excellent, thanks
<ms[m]> sestro: if you're lucky you might catch hkaiser now ;)
<hkaiser> yep, I'm here
<ms[m]> hkaiser: he had a question about locality ids
<ms[m]> not sure if you already saw it in the log, but this was the gist: https://gist.github.com/severinstrobl/bfba712aa4a03454e5fbab65bd70046e
<ms[m]> does that look correct to you?
<ms[m]> I can't judge...
<hkaiser> isn't find_remote_localities returning a future?
<hkaiser> no it isn't
<hkaiser> so yes, looks correct
<hkaiser> the output he sees means that HPX was not compiled with the MPI parcelport
<ms[m]> and I had another question for you hkaiser, is this define actually used somewhere: https://github.com/STEllAR-GROUP/hpx/blob/105c7e75faaa28b93760560164b02e0f34703f8f/CMakeLists.txt#L153?
<hkaiser> heller[m] : decided back then, that even if MPI is disabled in HPX, this is the behavior the user would expect - I disagreed - but alas
<ms[m]> so no mpi parcelport, but it finds the other locality... meaning some other parcelport is there
<hkaiser> ahh - no
<hkaiser> it finds two localities!
<heller[m]> woot?
<ms[m]> "found total of 2 localities"
<ms[m]> I think the question is about the `{0000...}`
<hkaiser> hey heller[m], didn't expect to wake you up here ;-)
<hkaiser> yah, tha doesn't look right indeed
<ms[m]> but I'll let sestro explain when he's back around
<ms[m]> blame it all on heller
<ms[m]> best way to summon him?
<hkaiser> I tried
<hkaiser> ms[m]: I'll have a look
<ms[m]> yep, thanks and no worries, just wanted to let you know there was a question for you...
<heller[m]> from my point of view, it looks correct, except the remote localities portion
<Yorlik> o/
<heller[m]> I'm not sure why this is related to the MPI parcelport?
<hkaiser> heller[m]: it isn't - just wanted to see if I can wake you up ;-)
<heller[m]> lol
<heller[m]> just remember: my decisions were always correct
<hkaiser> indeed
<heller[m]> it's just the world that isn't ready for them yet ;)
<hkaiser> ms[m]: btw, I can confirm the behavior
<ms[m]> 👍️
<ms[m]> who knows, maybe they're just printed wrong?
<hkaiser> ms[m]: yah, looks like it
<hkaiser> ms[m]: some #include is missing, it picks the wrong operator<<() overload
<hkaiser> I think...
<dkaratza[m]> <hkaiser> "ms, dkaratza[m]: toorrow I..." <- i thought you couldnt join so thats why i suggested tomorrow morning
<dkaratza[m]> I dont know what is better actually,
<dkaratza[m]> if you think its better to do it tomorow afternoon its fine with me
<dkaratza[m]> whatever you prefer
<ms[m]> anything works for me... hkaiser is all day tomorrow bad for you?
<hkaiser> yes, tomorrow is off limits
<ms[m]> and dkaratza today is no good for you? if yes, let's stick to tomorrow morning then
<dkaratza[m]> ms[m]: yeah, i have an appointment for administration issues and im not sure if i can make it
<dkaratza[m]> so tomorrow would be better
<ms[m]> all right, no problem, let's do tomorrow then
<ms[m]> what time?
<ms[m]> I'm flexible
<dkaratza[m]> anytime before 13:00 is fine
<dkaratza[m]> maybe 10?
<ms[m]> dkaratza: 10 is good
<ms[m]> rori: also for you?
<ms[m]> and gnikunj just in case you would happen to have the time...
<sestro[m]> <ms[m]> "I think the question is about..." <- Sry for answering late. Yes, indeed, the number of localities is correct, but they all are shown to have the same ID?
<sestro[m]> <hkaiser> "ms: some #include is missing, it..." <- Do you have an idea which one that could be?
<rori[m]> <ms[m]> "rori: also for you?" <- yep
<ms[m]> sestro: give hpx/runtime.hpp a try, though it's probablly not quite the correct one...
<sestro[m]> <ms[m]> "sestro: give hpx/runtime.hpp a..." <- No change, unfortunately.
<hkaiser> sestro[m]: it's a bug in our output routine for gids
<hkaiser> essentially it prints the value for a 32 bit integer
<sestro[m]> Okay, thanks for confirming.
<hkaiser> sestro[m]: also, please see https://github.com/STEllAR-GROUP/hpx/pull/5588 for a fix
<sestro[m]> <hkaiser> "sestro: also, please see https:/..." <- Thanks for the quick fix, now I get the output I would expect.
<hkaiser> sestro[m]: would you add a comment to the ticket, please?
K-ballo has joined #ste||ar
Yorlik has quit [Ping timeout: 245 seconds]
<K-ballo> I kinda hated it too
<ms[m]> K-ballo: thanks
<ms[m]> what's not to hate about it...
<ms[m]> what's the use of making it variadic?
<jedi18[m]> K-ballo: I noticed that the ranges v3 library uses static_cast<T&&> instead of std::forward, is std::forward just syntatic sugar or does it provide some additional functionality?
<K-ballo> ms[m]: obscure comma support.. FWD(foo<X, Y>{}.z)
<K-ballo> jedi18[m]: std::forward/move are about declaring intention, they exist for their names, they don't actually forward/move anything themselves
<K-ballo> std::forward has some additional checks it needs to perform due to T being explicitly provided, to prevent misuses, but that's not an additional functionality, it's just patching over its deficits
<jedi18[m]> Oh ok thanks, so I guess they are directly using static_cast to avoid the overhead of these additional checks
<K-ballo> no, the instantiation & lookup cost
<K-ballo> a "regular" C++ TU may end up having thousands of std::forward instantiations
<jedi18[m]> TU?
<K-ballo> translation unit, the unit of compilation
<hkaiser> ms[m]: is the HPX_MOVE macro meant to be used for the std::move algorithm as well?
<ms[m]> hkaiser: nope, I need to go back and change those to plain std::move
<hkaiser> ok, good - wouldn't compile anyways, I guess
<ms[m]> indeed
<jedi18[m]> Oh ok, so is that why we are replacing them with macros? So that it is taken care of by the preprocessor instead of the compiler?
<K-ballo> it's mainly to avoid all those instantiations and their cost, yes
<K-ballo> there are other advantages, less debug information
<gonidelis[m]> jedi18: you invoked the beast i see. that was a good morning lesson for me.
<jedi18[m]> Oh ok got it, thanks!
Yorlik has joined #ste||ar
Yorlik has quit [Ping timeout: 250 seconds]
FunMiles has joined #ste||ar
<FunMiles> I've defined a serializer for a custom class and compilation works, but at link time, I get an undefined symbol error:
<FunMiles> Undefined symbols for architecture x86_64:
<FunMiles> "hpx::traits::component_type_database<hpx::lcos::server::channel<hpx::IncomingWork<double, int, void>, hpx::IncomingWork<double, int, void> >, void>::get()", referenced from:
<FunMiles> int hpx::components::get_component_type<hpx::lcos::server::channel<hpx::IncomingWork<double, int, void>, hpx::IncomingWork<double, int, void> > >() in libAsyncSolver.a(AsyncSolverScripting.cpp.o)
<FunMiles> int hpx::components::get_component_type<hpx::lcos::server::channel<hpx::IncomingWork<double, int, void>, hpx::IncomingWork<double, int, void> > >() in libAsyncSolver.a(HPXInit.cpp.o)
<FunMiles> Am I missing an include? or do I have to define something else besides the two `serialize` functions?
Yorlik has joined #ste||ar
<FunMiles> Do I have to use the macro HPX_DEFINE_GET_COMPONENT_TYPE_STATIC ?
<hkaiser> FunMiles: hmmm
<hkaiser> looks like you missed one of the action macros
<hkaiser> difficult to tell from the distance
<FunMiles> I tried using the macro and the compiler complains that I am calling it with too many arguments. I'm trying to figure out why....
<hkaiser> if at all, then use it without the _STATIC suffix, but normally it's not needed at all
<hkaiser> FunMiles: hold on
<hkaiser> do you have the component registry macro?
<hkaiser> HPX_REGISTER_COMPONENT_MODULE();
<hkaiser> and HPX_REGISTER_COMPONENT(component-type, unique-component-name);
<FunMiles> @hkaiser: As in hpx component? No. I didn't expect to use a component in that sense. I am trying to put some composite data that include matrix-type data in a channel.
<hkaiser> ahh, now I see it
<hkaiser> it's related to the channels
<hkaiser> what HPX verion do you use?
<hkaiser> version*
<FunMiles> Yes. If I use a local channel, no problem. But as I will be targeting distributed applications, I thought I'd try to address the serialization for that.
<FunMiles> 1.7 I believe.
<hkaiser> ok
<hkaiser> I think I have not updated channels to automatically be usable with special macros ...
<FunMiles> CMake says 1.8.0 in the version defines.
<hkaiser> you need a using channel_data_type = hpx::IncomingWork<double, int, void> ; HPX_REGISTER_CHANNEL(channel_data_type);
<hkaiser> I meant channels are not usable without special macros yet
<hkaiser> that's still a todo :/
<FunMiles> :)
<FunMiles> ../HPX/Solvers/HPXLDLt_impl.h:1146:1: error: no function template matches function template specialization 'component_heap_helper'
<FunMiles> HPX_REGISTER_CHANNEL(channel_data_type);
<hkaiser> *grumble*
<FunMiles> Let me move the macro outside of the namespace.
<hkaiser> FunMiles: so I'd need to see the code in order to be able to help
K-ballo1 has joined #ste||ar
<pedro_barbosa[m]> is it possible to use gprof on HPXCL?
FunMiles has quit [*.net *.split]
K-ballo has quit [*.net *.split]
K-ballo1 is now known as K-ballo
FunMiles has joined #ste||ar
<FunMiles> hkaiser: I don't know what you received of my last messages. The code now compiles and links, so that is good.
<FunMiles> hkaiser: I read a paper in which you are a co-author : "ZERO COPY SERIALIZATION USING RMA IN THE HPX DISTRIBUTED TASK-BASED RUNTIME". I presume what is described in there for vector<T> is what compute::vector does.
<FunMiles> I'm wondering how easy/difficult it would be to extend std::unique_ptr<T []> to make use of the necessary allocator to not have copy.
Yorlik has quit [Ping timeout: 260 seconds]
FunMiles has quit [Remote host closed the connection]
FunMiles has joined #ste||ar
FunMiles has quit [Ping timeout: 252 seconds]
FunMiles has joined #ste||ar
FunMiles has quit [Ping timeout: 250 seconds]
FunMiles has joined #ste||ar
FunMiles has quit [Ping timeout: 252 seconds]
FunMiles has joined #ste||ar
FunMiles has quit [Ping timeout: 250 seconds]
FunMiles has joined #ste||ar
tufei__ has quit [Read error: Connection reset by peer]
<hkaiser> FunMiles: let's discuss in detail another day, I'm off for today - sorry
<hkaiser> and glad that the code links now
hkaiser has quit [Quit: Bye!]
FunMiles has quit []
FunMiles has joined #ste||ar
<FunMiles> Is channel.set blocking?
<FunMiles> I figured it out. For non local channel, set will be blocking until the channel is associated, or it is constructed on the locality.