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/
K-ballo has quit [Quit: K-ballo]
diehlpk_work has quit [Remote host closed the connection]
bita has joined #ste||ar
bita has quit [Ping timeout: 258 seconds]
<gonidelis[m]> Do we plan on providing ranges overloads for the numeric header?
K-ballo has joined #ste||ar
<gonidelis[m]> K-ballo: what's the difference between `std::bind` and `std::bind_front`?
<bering[m]> K-ballo knows it certainly more precisely, but the former binds any parameter, while the latter only the first. In some later standard std::bind has been deprecated / removed(?) because lambdas fit its use case better.
<bering[m]> Oh, does not seem like std::bind is actually deprecated, yet.
<gonidelis[m]> huh
<gonidelis[m]> seems like we weakened `std::bind`...
<gonidelis[m]> if lambdas did the work, then why introduce std::bind_front
<gonidelis[m]> ?
<bering[m]> Probably because the syntax is a little bit less convoluted. If you bind only the first parameter, you do not need markers and such. With lambdas it is a little bit more verbose. Have not followed the discussion, though.
<gonidelis[m]> freenode_bering[m]: these are the exact arguments I found on SO so you are 100% right. Seems like a controversial topic after all
<ms[m]> diehlpk_work: we have the usual hpx meeting in an hour, do we need to discuss anything related to gsoc?
<K-ballo> bind has not been deprecated
<K-ballo> bind can sometimes do a better job than lambdas
mdiers[m] has left #ste||ar ["User left"]
<K-ballo> one of the problems with bind is that it tries to do too much, bind_front does less
<K-ballo> another problem is in the handling of variadic parameters, bind_front can handle those
<K-ballo> there are some vocal individuals that would very much like to deprecate bind, but we have no plan as a committee to do that, there would not be consensus
<K-ballo> even the removal of the original binders proved to be a problem
<K-ballo> bering[m]: bind will bind any sort of parameters, in any position, in any order
<bering[m]> I know, but would lambdas not do the same?
<K-ballo> not quite
<K-ballo> this being C++, the answer is always "kinda but not entirely"
<bering[m]> :)
<K-ballo> lambdas have a single op(), bind() has two, bind_front() has four
<K-ballo> a lambda can never propagate constness/value-category, bind can never propagate value-category
<bering[m]> Good thing we have an expert here. One can learn something by accident. ;)
<bering[m]> Lambdas can be templated, so they can perfect-forward parameters right? Also, since C++17(?) there is std::as_const to capture variables as constants. Is it not enough to propagate constness/value-category or am I completely off track?
<K-ballo> that's not what propagating means here
<K-ballo> auto f = ...; // lambda, bind, or bind_front
<K-ballo> f(); // mutable lvalue call
<K-ballo> as_const(f)(); // const lvalue call
<K-ballo> std::move(f)(); // rvalue call
<bering[m]> Have to play around with this a bit.
<bering[m]> Ah, I see.
<gonidelis[m]> ms[m]: is this happening?
<gonidelis[m]> is hkaiser still out?
<ms[m]> gonidelis[m]: is what happening?
<ms[m]> he is, but we'll have a short meeting in any case
<gonidelis[m]> cool
<gonidelis[m]> K-ballo: so is it true that `bind_back` has not been added due to lack of compelling use cases?
<K-ballo> something like that, the use cases for bind_back are much less common
<K-ballo> variadic parameters tend to go last in the function
<K-ballo> hpx has a number of those odd cases, inherited form the C++98 faux-variadic era, still four or five times less than the bind_front counterpart
<K-ballo> void fun(x, y, z, args...); -> bind_front(f, x, y, z); is the target use case
<K-ballo> void fun(args..., x, y, z); not much of a thing since C++11
diehlpk_work has joined #ste||ar
<jedi18[m]> Ok so since the gsoc deadline is over and no more students will show up so can I attempt the remaining algorithms https://github.com/STEllAR-GROUP/hpx/issues/5156 here? (was waiting since those were good entry level tasks for new students)
<bering[m]> K-ballo: Thank you for clarification. Really valuable.
geoboom has joined #ste||ar
<geoboom> Hi, I want to contribute to this project to gain experience working in a C++ codebase. I've built HPX and worked through examples up to "Remote execution with actions: hello world" and I want to try implementing a simple matrix multiplication using HPX. Is there some example code I could refer to? I found
<geoboom> https://github.com/STEllAR-GROUP/SC15_Examples but `make` always gave some errors. :(
<ms[m]> jedi18[m]: go for it! probably still a good idea to comment saying which one(s) you'll work on, there might be interest even after the gsoc deadline, but most likely you'll be safe just ploughing through them
<ms[m]> geoboom: the best source for examples that actually compile is the hpx repo itself
<ms[m]> there's also this: https://github.com/DavidPfander-UniStuttgart/MatrixMultiplicationHPX which might also not compile anymore but it might give you some ideas about how to implement matrix-matrix multiplication in hpx
<jedi18[m]> <ms[m] "jedi18[m]: go for it! probably s"> Oh ok thanks!
<gonidelis[m]> jedi18: thanks!
<geoboom> ms[m] thank you
<pedro_barbosa[m]> diehlpk_work: so I was trying to compile an example from the HPXCL repository (Link to example: https://github.com/STEllAR-GROUP/hpxcl/blob/master/examples/cuda/build_kernel.cpp) but I'm having some trouble linking the correct files. The current CMake file I'm using looks like this (GIST: https://gist.github.com/PADBarbosa/d4426d0a6788562061abed8304dba51e) and the output I get is the following (GIST:
<pedro_barbosa[m]> https://gist.github.com/PADBarbosa/bfb7ee3b6d1ada3ebf77e04521e85b8e). I'm using HPX version 1.5.1 and CUDA version 10.2, also the example works fine in the examples directory
<diehlpk_work> pedro_barbosa[m], I will have a look later today
geoboom has quit [Ping timeout: 240 seconds]
<diehlpk_work> pedro_barbosa[m], Can you provide more details?
<diehlpk_work> which OS and CMake?
<pedro_barbosa[m]> cmake version 3.16.3
<pedro_barbosa[m]> Ubuntu 20.04
<diehlpk_work> pedro_barbosa[m], Are you building the main branch?
<diehlpk_work> or master
<pedro_barbosa[m]> I used the hpxcl-master
<pedro_barbosa[m]> not sure if that's what you meant
<diehlpk_work> Yes
<diehlpk_work> pedro_barbosa[m], Do you have multiple installations of hpx?
<diehlpk_work> I can not reproduce your bug on Fedora
<pedro_barbosa[m]> only this one I believe, I used to have version 1.6 but I deleted all files related to it before installing 1.5.1
<pedro_barbosa[m]> did you use the same cmake file that I sent? I thought I was missing something there
<diehlpk_work> pedro_barbosa[m], Are you using a build folder?
<diehlpk_work> or do you build in the main folder?
<pedro_barbosa[m]> I was trying to compile it on a new folder yes
<diehlpk_work> Ok, I assume you did a git clone and cd hpxcl or?
<diehlpk_work> But did you run cmake directly in the hpxcl folder or did you first generated a new folder?
<diehlpk_work> cd hpxcl && mkdir build && cd build && cmake ..
<pedro_barbosa[m]> Yes, I downloaded the repository built and installed hpxcl and can run the example from the folder, but then I wanted to compile it in a new folder so I would learn how to do it when I started making other programs
<diehlpk_work> Ok, now I understand
<diehlpk_work> pedro_barbosa[m], Ok, that feature needs more work
<diehlpk_work> and is currently missing in hpxcl
<diehlpk_work> I can work on a proper way to use hpxcl in a new project.
<diehlpk_work> The best way to proceed for now is to use your own example in the example folders
<pedro_barbosa[m]> And then add it to the CMakefiles.txt and compile?
<diehlpk_work> Yes
<diehlpk_work> I never used hpxcl in a different project and this feature was never implemented
<pedro_barbosa[m]> Alright, thank you
<diehlpk_work> ms[m], Can you point me where we generate the file for the find_package command for hpx?
<ms[m]> and most of the logic for generating it is in here: https://github.com/STEllAR-GROUP/hpx/blob/master/cmake/HPX_GeneratePackage.cmake
<diehlpk_work> ms[m], Thanks, I will have a look and adapt if for hpxcl
<gonidelis[m]> K-ballo:
<gonidelis[m]> yt/
<gonidelis[m]> ?
<K-ballo> gonidelis[m]: only partially
<gonidelis[m]> on your wandbox () operator overloading
<gonidelis[m]> like ` void operator()() const & { std::cout << "const lvalue\n"; }`
<gonidelis[m]> what does `const &` mean?
<gonidelis[m]> K-ballo: ^^
<zao> gonidelis[m]: See https://en.cppreference.com/w/cpp/language/member_functions "ref-qualified member functions"
<gonidelis[m]> zao: thanks
<gonidelis[m]> !
hkaiser has joined #ste||ar
<gonidelis[m]> how does gdb show the execution stack when i have a parallel call?
<gonidelis[m]> call stack*
<hkaiser> gonidelis[m]: thread N swutches to the thread 'N' and then bt will give you the stack back trace
<gonidelis[m]> hkaiser: i apologize for this awful welcoming message...
<hkaiser> lol
<gonidelis[m]> hkaiser: of course a dbg-related question would be the first thing you would need to answer after a vacation. welcome back btw :) and thanks!
<gonidelis[m]> what do yo umean thread N switches to the thread 'N'?
<hkaiser> 'thread 0', 'thread 1', etc. switch to the thread with the corresponding number
<gonidelis[m]> aren't these threads run in parallel?
<hkaiser> sure, but you can look at one thread back trace at a time only
bita has joined #ste||ar
<K-ballo> gonidelis[m]: you know what `const` by itself there means, right?
<gonidelis[m]> const means that the expression is constant
<gonidelis[m]> K-ballo:
<K-ballo> what expression?
<gonidelis[m]> the return on?
<gonidelis[m]> one*
<K-ballo> no
<gonidelis[m]> so?
<K-ballo> so?
<gonidelis[m]> so what expression?
<gonidelis[m]> it's about the member functin
<gonidelis[m]> function*
<K-ballo> it's a qualifier for the implicit *this param
<gonidelis[m]> wow
<gonidelis[m]> i had no idea
<gonidelis[m]> does not mention it anywhere here at least
<gonidelis[m]> i wouldn't imagine it either
<K-ballo> "In the body of a cv-qualified function, *this is cv-qualified,"
<K-ballo> that means in a const function, *this is qualified with const
<K-ballo> that means const is a qualifier for *this, the implicit param
<K-ballo> *const-qualified function
<K-ballo> " lvalue ref-qualifier: the implicit object parameter has type lvalue reference to cv-qualified X"
<K-ballo> "rvalue ref-qualifier: the implicit object parameter has type rvalue reference to cv-qualified X "
<K-ballo> as you can see, the same goes for & and &&
<K-ballo> ("the implicit object parameter" being *this)
<gonidelis[m]> so this means that if i use *this within this member function, it will be used as a const & object
<K-ballo> "used as"? it will be a
<gonidelis[m]> it will be qualified as
<K-ballo> no, types are qualified
<gonidelis[m]> hm ok... so if this*'s type is T &const within this member function
<gonidelis[m]> Without the "if"