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
diehlpk_work has quit [Ping timeout: 260 seconds]
<gonidelis[m]> in that example, is the `operator<<` overloading taking place throughout the `ex` namespace? like, whenever I use `<<` with types of that namespace it bahaves with the way specified in the funciton body?
<gonidelis[m]> more like it
<K-ballo> operators aren't special other than in syntax
<K-ballo> you get ordinary lookup and sometimes argument dependent lookup too
<gonidelis[m]> "operators aren't special other than in syntax" ?
<K-ballo> change `operator<<` for `foo`, adjust the call sites, and the behavior remains unchanged
<gonidelis[m]> oh!
<gonidelis[m]> huh
<gonidelis[m]> that's..... type dispatching/
<gonidelis[m]> "
<gonidelis[m]> ?
<K-ballo> not sure what you have in mind
<gonidelis[m]> forget it... wtf no
<gonidelis[m]> it's just simple function overloading
<gonidelis[m]> no/
<gonidelis[m]> ?
<K-ballo> just regular function, no overloading
<gonidelis[m]> what's wrong with me
<gonidelis[m]> yes
<gonidelis[m]> just takes types that use the same functio name
<gonidelis[m]> it's called function call for god's sake ;p
<K-ballo> "types"?
<K-ballo> takes types sounds like templates, there are no templates here
<gonidelis[m]> types objects of different types
<gonidelis[m]> no
<K-ballo> "type objects"? not sure what you mean
<gonidelis[m]> takes different objects of same type
<gonidelis[m]> like every normal function
<gonidelis[m]> excuse my mind is melting from triviality at this point
<K-ballo> that's right, normal function, each parameter has a single fixed well known type, arguments may have whatever types as long as they are compatible
<gonidelis[m]> ok back to the original question.
<gonidelis[m]> actually this answers all of my questions.
<gonidelis[m]> nice!
<K-ballo> what was the original question?
<gonidelis[m]> (this somehow will end up in tag_invoke later in the talk... lets see how)
<gonidelis[m]> yeah my question is why does not work with possum
<gonidelis[m]> was*
<K-ballo> possum is not an animal
<gonidelis[m]> but of course it does not
<gonidelis[m]> yes
<gonidelis[m]> converting << to foo helped
<gonidelis[m]> me understand why ^^
<gonidelis[m]> just to make this clear though, is the operator<< overloaded in the namespace? or can i still use it with the standard way within the namespace?
<gonidelis[m]> ahhh I can still use it... simple overloading, right
<K-ballo> not sure what you have in mind.... are you asking about hiding?
<K-ballo> technically the operator<< is not overloaded in the namespace, there's only one of them there
<gonidelis[m]> but i can still use it with the default way
<K-ballo> what's the "default way"?
<gonidelis[m]> std::cout << ex::sheep{}.age << "\n";
<K-ballo> you mean the many overloads in std::basic_ostream and std ?
<gonidelis[m]> not through the sound function
<gonidelis[m]> yes
<gonidelis[m]> haha
<gonidelis[m]> yes through the many overloads
<gonidelis[m]> i just added one more (if that's what you are saying), nice
<K-ballo> no, you didn't
<gonidelis[m]> ?
<K-ballo> overloads come from within a single scope, in the ex namespace scope there's only one op<<
<gonidelis[m]> ok
<gonidelis[m]> but i can still use op<< within the ex namespace without providing the arguments defined in my overload
<K-ballo> yes, you are not calling the one defined in ex namespace
<gonidelis[m]> but it's not overloading cause it's a different namespace
<K-ballo> different scope, yes
<gonidelis[m]> how do you call the thing where you call a function and the proper "overload" (that's probably not the word) is being selected from the according namespace, OHHHHHH!!!!!! ADL?????
<gonidelis[m]> amazing!! (if that's it)
<K-ballo> well, not for something like age, but for other types it would be
<K-ballo> the one for int is a member function of std::basic_ostream https://en.cppreference.com/w/cpp/io/basic_ostream/operator_ltlt
<K-ballo> in that sense operators *are* different than plain `foo` functions, in that they do extra lookup (as in proposed uniform function call syntax)
<K-ballo> `x << y` is looking both for `x.operator<<(y)` and `operator<<(x, y)`
<K-ballo> if you were streaming something like an std::string then https://en.cppreference.com/w/cpp/string/basic_string/operator_ltltgtgt yes, that's adl
<gonidelis[m]> yes ok!
<gonidelis[m]> "proposed uniform function call syntax" what's that
<gonidelis[m]> ?
<K-ballo> something to extend the operators extra lookup to regular functions
<gonidelis[m]> amazing
<gonidelis[m]> i mean how i ended up in adl so naturaly
<gonidelis[m]> the proposed uniform thingy is just an extra block
<gonidelis[m]> why is this unspecified behavior?
<K-ballo> why would it be?
<gonidelis[m]> well the guy says that gcc and clang call the std version, while msvc calls user::tie
<gonidelis[m]> i just dont get why
<K-ballo> the std one is a better match
<K-ballo> is the guy explicitly including just <memory>? if so he may be refering to the fact that any <std> header may or may not include any or every other <std> header
<gonidelis[m]> very nice catch
<gonidelis[m]> i don't think he does it explicitly
<gonidelis[m]> he just want the example to be minimally reproducable
<gonidelis[m]> why do you say "is a better match" tho? and by just saying that don't you verify that is unspec. beh?
<K-ballo> better match is standard overload resolution terminology
<gonidelis[m]> what!? really
<gonidelis[m]> lol
<K-ballo> what's unspecified is whether or not you get the std::tie candidate
<K-ballo> std::tie is defined in <tuple>, but any other header may include it as well
<gonidelis[m]> but why is it a better match?
<K-ballo> if you include tuple then the behavior is well defined, the std one is called
<gonidelis[m]> ok got it, why is it unspec. just because you cannot know if the header is included
<gonidelis[m]> nice, but why std is better match?
<K-ballo> find out how std::tie is defined
<gonidelis[m]> cause of the lack of `const`ness?????????????? 0.0
<K-ballo> yes
<gonidelis[m]> AMAZING!
<gonidelis[m]> wow!
<gonidelis[m]> blown away
<K-ballo> X& is a better match for X& than X const& is
<gonidelis[m]> stupid question but does make_shared give a ref?
<K-ballo> a ref to what?
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: Bye!]
<zao> Ooh, found out about `make_shared_for_overwrite` today, looks nice to be able to skip the init bit.
hkaiser has joined #ste||ar
K-ballo has joined #ste||ar
<dkaratza[m]> hkaiser: today we have a meeting at 16:00 CET but I cannot see anything in my calendar. Is our meeting still valid?
<hkaiser> dkaratza[m]: yes, I have it on my calendar, but I was not able to do anything
<hkaiser> do you want to meet?
<dkaratza[m]> <hkaiser> "do you want to meet?" <- sure! same link?
<hkaiser> dkaratza[m]: yes
<dkaratza[m]> <hkaiser> "dkaratza: yes" <- ok
<mdiers[m]> hkaiser: https://github.com/STEllAR-GROUP/hpx/issues/5802 , I hope it is reproducible
<hkaiser> mdiers[m]: thanks, I have not tried to reproduce yet
diehlpk_work has joined #ste||ar
<gonidelis[m]> dkaratza: hkaiser link?
<dkaratza[m]> hkaiser: the functions of the current header `hpx/future.hpp` should be plaved in the same table as the functions of the `hpx/local/future.hpp` or in a separate one? Or are these also the distributed version?
<hkaiser> yes, same table
nanmiao has joined #ste||ar
jedi18[m] has quit [Quit: You have been kicked for being idle]
<dkaratza[m]> hkaiser: I updated the pr. you should be able to check the docs now
<hkaiser> cool, thanks!
nanmiao has quit [Quit: Client closed]
<diehlpk_work> Why do we need cublas in HPX?
<diehlpk_work> With the new restructured cuda folder strucuture, we have issue with finding cublas_v2.h
<diehlpk_work> hkaiser, Could you please have a look
<hkaiser> diehlpk_work: this looks like an older version of HPX, is this master?
<diehlpk_work> hkaiser, No, that is master from this morning
<hkaiser> diehlpk_work: hold on, no - my fault
<diehlpk_work> :(
<hkaiser> diehlpk_work: ok, will fix asap
<diehlpk_work> Thanks
<hkaiser> diehlpk_work: the tests didn't reveal this
<diehlpk_work> Therefore we have me to test HPX on perlmutter
<hkaiser> diehlpk_work: what compiler is that?
<diehlpk_work> g++ (GCC) 11.2.0
<hkaiser> diehlpk_work: I'm not quite sure why this is failing to compile, now that I have a closer look
<diehlpk_work> hkaiser, Ok, it is not super urgent. I wanted to test the latest hpx and octotiger on perlmutter
<hkaiser> I will try to change the line 402 and hope that everything else is just caused by the compiler being confused :/
<hkaiser> is that with CUDA enabled?
<diehlpk_work> Just to see if the hanging goes way or to reduce the number of MPI threads
<diehlpk_work> Yes, It works without cuda
<diehlpk_work> But with CUDA the error shows
<hkaiser> so this is compiled with NVCC?
<diehlpk_work> No
<diehlpk_work> with CC which is g++
<diehlpk_work> Octotiger only compiles the kenerls using nvcc
<hkaiser> those errors don't look like being generated by gcc
<diehlpk_work> But let me double check
<hkaiser> what file is failing to compile there?
<diehlpk_work> Yes, you were right it is nvcc
<hkaiser> what CUDA version is this?
<diehlpk_work> [ 3%] Building CUDA object CMakeFiles/hydrolib.dir/src/unitiger/hydro_impl/hydro_kernel_interface.cpp.o
<diehlpk_work> 11.4
<hkaiser> ok