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
K-ballo has quit [Quit: K-ballo]
diehlpk has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
diehlpk has quit [Client Quit]
hkaiser has quit [Quit: Bye!]
inertia has joined #ste||ar
K-ballo has joined #ste||ar
wash_ has quit [Read error: Connection reset by peer]
wash_ has joined #ste||ar
jehelset has joined #ste||ar
hkaiser has joined #ste||ar
<hkaiser> jedi18[m]: because it's a bug?
<jedi18[m]> Shall I add the correct overloads then? We'll probably need to change the implementation too then
<jedi18[m]> Shall I keep this old one around as another algorithm with a different name?
<K-ballo> what are the differences?
<jedi18[m]> Ours takes in these
<jedi18[m]> ```
<jedi18[m]> FwdIter first, std::size_t count, FwdIter2 s_first, FwdIter2 s_last, Pred&& op
<jedi18[m]> ```
<jedi18[m]> The standard specifies these
<jedi18[m]> ForwardIterator first, ForwardIterator last, Size count, const T& value, BinaryPredicate pred
<jedi18[m]> ```
<jedi18[m]> ```
<jedi18[m]> No value parameter for one
<jedi18[m]> Plus why are there different iterators in the our one?
<K-ballo> i'm still not sure exactly which overloads you are comparing?
<K-ballo> there's just so many
<jedi18[m]> Ok well we have just one overload here https://github.com/STEllAR-GROUP/hpx/blob/af33761c7d195455e58529501e96ee8ca5dff8df/libs/core/algorithms/include/hpx/parallel/algorithms/search.hpp#L440 (the other one is just the same one with an execution policy)
<jedi18[m]> But here if you scroll down to the search_n overloads https://eel.is/c++draft/alg.search , they're quite different from ours
<K-ballo> yes, there are 6 search_n overloads, which one are you comparing to hpx's second one?
<jedi18[m]> Well that's the thing, none of them match our overload
<jedi18[m]> But I'm referring to the fourth one
<jedi18[m]> hkaiser: Haha sure, but do you want me to keep the old one around? I'm guessing it was added for a reason?
<hkaiser> don't think so, let's make the API conforming, the tag_invoke overloads are new, no reason to maintain compatibility
<K-ballo> oh, I see what's going on
<K-ballo> the standard's search_n isn't the _n version of search
<K-ballo> it's a related but completely different algorithm that just happens to clash in name
<hkaiser> uhh?
<K-ballo> search looks for a sub-range inside an outer-range
<K-ballo> search_n looks for a sub-range of N consecutive v values
<K-ballo> so search_n(count, value) = search(repeat(count, value))
<hkaiser> so we completely miss the actual search_n
<K-ballo> some unfortunate naming
<jedi18[m]> Yeah, so what shall I change the name of the current search n to?
<jedi18[m]> search_range_n?
<K-ballo> the only viable name for that one is search_n
<jedi18[m]> But we do need the standard search_n
<K-ballo> yes
<jedi18[m]> So....? Adding overloads for both algorithms with the same name is probably problematic so I guess that's not an option?
<jedi18[m]> So that only leaves removing the current search_n?
<hkaiser> let's rename what we have
<K-ballo> I'd drop current search_n
<hkaiser> ok
<K-ballo> can't think of another name that'd make sense
<hkaiser> I have no recollection where it came from
<K-ballo> from the early days, grant wrote it
<K-ballo> was it in the original parallel algorithms ts?
<K-ballo> fun stuff
<hkaiser> yah, but it didn't specify it properly
<hkaiser> first paper is N3989
<K-ballo> oh no, it was in the post 11 draft.. what?
<K-ballo> it was in C++11...
<K-ballo> and C++03 too, lol...
<K-ballo> must come all the way from STL, I never noticed it was different from search
<hkaiser> when was it removedchanged?
<K-ballo> never
<K-ballo> lol
<hkaiser> so we have two versions of search_n now?
<K-ballo> uhm, define version? there's only ever been one standard version
<K-ballo> our search_n is made up
<hkaiser> ahh
<hkaiser> ok
<hkaiser> let's blame Grant ;-)
<gonidelis[m]> hkaiser: by pinning threads we are trying to sustain the same threads within a certain socket without them jumping around and changing context?
<hkaiser> gonidelis[m]: yes, pinning even to cores, not only sockets
<gonidelis[m]> huh
<gonidelis[m]> hkaiser: what about likwid not being available to rostam? are there other options except source installation?
<hkaiser> gonidelis[m]: what other options might there be?
<hkaiser> you can also ask Alireza to install it, but that might take some time as he's busy with the transition to redhat
<gonidelis[m]> ok
diehlpk has joined #ste||ar
<pedro_barbosa[m]> Is it possible to set environment variables for the kernel launch in HPXCL?
<hkaiser> pedro_barbosa[m]: if there is code that reads the environment variables, yes - otherwise it might not have any effect
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
diehlpk has quit [Client Quit]
diehlpk has joined #ste||ar
diehlpk has quit [Client Quit]
diehlpk has joined #ste||ar
<gonidelis[m]> hkaiser: do i have to build likwid with clang too?
<gonidelis[m]> in order towork for openmp clang
<hkaiser> gonidelis[m]: don't think so
<gonidelis[m]> thanks
<hkaiser> it's a C-based library and fully self-contained
inertia is now known as inertia[away]
<gonidelis[m]> hkaiser: hey?
<hkaiser> here
<gonidelis[m]> i thought you were staying
diehlpk_work has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
jehelset has quit [Remote host closed the connection]
<hkaiser> ms[m]: yt?
jehelset has joined #ste||ar
<gonidelis[m]> hkaiser: how do i verify that thread binding actually happened. likwid says so, but what if I use the other tools like numactl and omp affinity?
<diehlpk> hkaiser: Could you please have a look into this bug? It seem to be some issue with the parcelport on perlmutter
<dkaratza[m]> do we have a BLAS implementation?
diehlpk_work has quit [Ping timeout: 264 seconds]
<diehlpk> dkaratza[m]: No, I do mot know we have that
<hkaiser> diehlpk: difficult to tell without context
<hkaiser> gonidelis[m]: performance should improve if affinities are defined
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
inertia[away] is now known as inertia
inertia is now known as inertia[away]
diehlpk has quit [Quit: Leaving.]
diehlpk has joined #ste||ar
diehlpk_work has joined #ste||ar
diehlpk has left #ste||ar [#ste||ar]
inertia[away] is now known as inertia
inertia is now known as inertia[away]
<diehlpk_work> hkaiser, Should I open some ticket for the parcelport crash on Perlmutter?
<hkaiser> sure, feel free - however, not sure how to fix or even diagnose it without more context
<diehlpk_work> hkaiser, What context is missing?
<hkaiser> how to reproduce? does it happen on other platforms?
<diehlpk_work> Compile Octo-Tiger on Perlmutter with Cray gcc and Cray MPI
<diehlpk_work> Submit a job on a single node and HPX will crash each time
<hkaiser> does it happen in Debug mode as well?
<diehlpk_work> Need to check
<hkaiser> why does it fail in the MPI parcelport if you run with one locality only?
<hkaiser> diehlpk_work: but we can sit together next time we meet at CCT and have a look
<diehlpk_work> I do not run on one locailty
<diehlpk_work> I run one 4 localities
<diehlpk_work> We need one locality per GPU
<diehlpk_work> Perlmutter has four GPUs so I need to run on four localities and assign the cores equally to them
<hkaiser> ok, understand
<hkaiser> diehlpk_work: does it crash with two localities as well?
<diehlpk_work> hkaiser, I think that I found the issue
<hkaiser> what is it?
<diehlpk_work> It seems HPX can not handle some slurm variable
<diehlpk_work> --gpus-per=task=1 might be some issue
<diehlpk_work> I am not sure
inertia[away] is now known as inertia
inertia is now known as inertia[away]
inertia[away] is now known as inertia
inertia is now known as inertia[away]
K-ballo has quit [Remote host closed the connection]
K-ballo has joined #ste||ar
inertia[away] is now known as inertia