01:46 <hkaiser> gnikunj[m]: yt?

10:11 <gonidelis[m]> what's the purpose of having just an `ExPolicy` here as an argument, compared to the rvalue ref argument in the `parallel()` overload?

10:23 <gonidelis[m]> K-ballo: yt??

12:18 <gonidelis[m]> hkaiser: please ping me whenever you have a spare 5 minutes within the day

12:26 <hkaiser> gonidelis[m]: will do, need some coffee and breakfast first

12:40 <gonidelis[m]> hkaiser: sure

15:44 <hkaiser> ms[m]: yt?

15:47 <ms[m]> hkaiser: hey

15:49 <hkaiser> ms[m]: hey

15:49 <hkaiser> ms[m]: I'm struggling with build system settings again

15:50 <hkaiser> ms[m]: for instance jenkins/cscs/clang-oldest sets NETWORKONG=OFF, does that mean that DISTRIBUTED_RUNTIME is off as well?

15:51 <hkaiser> the actual question is, how do I disable tests/examples that have to run in distributed (num_localities > 1)?

15:51 <ms[m]> nope, the first does not imply the second

15:52 <hkaiser> I di have this: https://github.com/STEllAR-GROUP/hpx/pull/4858/files?file-filters%5B%5D=.txt#diff-d1a6e5e59d3d682b1ad371b090f2b19d49c32d0e893c77b53ed262ef1f8b13b4R9-R11

15:52 <ms[m]> HPX_WITH_NETWORKING=OFF implies that things will run on one locality for sure, so if you need more than one locality that has to be on

15:52 <hkaiser> but the tests are run anyways

15:53 <ms[m]> those are independent I suppose

15:53 <hkaiser> I figured as much ;-)

15:53 <ms[m]> or does the distributed resiliency module actually not work with just one locality?

15:54 <hkaiser> should I just change the tests themselves to exit gracefully if num_localities == 1?

15:54 <hkaiser> yah, the tests need more than one locality

15:55 <ms[m]> it sounds like you want to disable the tests if HPX_WITH_NETWORKING=OFF

15:55 <ms[m]> or that ^

15:55 <hkaiser> ok

15:55 <hkaiser> thanks

15:55 <ms[m]> but the module itself is fine with just one locality, right?

16:05 <hkaiser> ms[m]: I think so, yes

16:06 <weilewei> hkaiser are we meeting today?

16:06 <hkaiser> weilewei: I wasn't planning to meet - do you want/need to?

16:07 <weilewei> hkaiser I see, not much for update, let's skip it today then.

16:07 <hkaiser> ok

16:07 <hkaiser> I'll be at cct tomorrow morning

16:07 <weilewei> hkaiser I see, I can be there tomorrow morning then

16:08 <weilewei> I plan to run some experiments today (parameter sweep)

16:08 <hkaiser> if you like, sure - around 10 should be fine

16:16 <weilewei> Great, then I will be there tomorrow around 10

16:54 <hkaiser> gonidelis[m]: yt?

17:16 <gonidelis[m]> sorry

17:17 <gonidelis[m]> hkaiser: no i am

17:17 <hkaiser> would you have time to talk now?

17:17 <gonidelis[m]> yes please

17:17 <hkaiser> gonidelis[m]: https://lsu.zoom.us/j/3340410194

17:19 <gonidelis[m]> hkaiser: i am in

18:11 <gonidelis[m]> hkaiser: you suggested that I abandon `iterator_range` and create a more high level corresponding function obejct instead, right?

18:13 <hkaiser> no

18:14 <hkaiser> I suggested that you don't create an overload of make_iterator_range in the util namespace

18:15 <gonidelis[m]> ok

19:43 <weilewei> what is the hpx command line option that prints hpx idle rate periodically? hkaiser

19:44 <hkaiser> weilewei: sec

19:44 <weilewei> yup, sure

19:44 <hkaiser> weilewei: https://hpx-docs.stellar-group.org/tags/1.5.0/html/manual/launching_and_configuring_hpx_applications.html#hpx-options-related-to-performance-counters

19:45 <weilewei> --hpx:print-counter-interval ?

19:45 <hkaiser> nod

19:58 <weilewei> hkaiser different threads have different thread idling pattern, what should I look into?

19:59 <hkaiser> that's not deterministic

19:59 <hkaiser> but you know that some tasks are long running (walkers) leading to low idle-rates

20:00 <weilewei> Yes

20:00 <hkaiser> other tasks are short (accumulators)

20:00 <hkaiser> look at APEX traces

20:01 <hkaiser> what I'd suggest is to look into correlation of the overall idle-rate and execution time vs. number of walkers/accumulators

20:01 <weilewei> I see, let me try to figure that out

20:03 <weilewei> The overall idle-rate, is it represented as /threads/{locality#0/total}/idle-rate ?

20:28 <hkaiser> weilewei: yes

20:28 <hkaiser> actually for any locality#N

20:30 <hkaiser> weilewei: if you specify /threads{locality#*}/idle-rate on the command line you'll see only the overall numbers

20:44 <weilewei> I saw the printout at the end: /threads{locality#0/total}/idle-rate,1,61.689660,[s],6491,[0.01%], does it mean that the overall idle rate is 64.49%?

20:44 <weilewei> hkaiser ^^

20:46 <hkaiser> weilewei: yes

20:46 <hkaiser> that's across all cores

20:46 <weilewei> good, then I will do a parameter sweep with idle rate enabled

20:47 <hkaiser> nod

20:47 <weilewei> and another same experiment but without idle rate (Release build)

20:47 <hkaiser> weilewei: the idle-rate sweep should be don eusing release as well

20:48 <weilewei> Oh, I see, then I will build a Release version, good to know!

21:41 <weilewei> hkaiser for 1 walker and 1 accumulator case, I found the overall idle rate is 96.70%, and I noticed most of idle rate is 99%, except one 0.62%

21:42 <weilewei> I think 47 physical cores are being idle in most cases, because only 1 long-running walker

21:46 <gnikunj[m]> hkaiser: turns out it was a stupid bad memory access in 1d stencil replay example. I've corrected it and also changed the parameters of other performance test examples to mitigate the time out issue. Things should build and execute as expected now!

21:46 <gnikunj[m]> apologies for the 2d delay

21:51 <gnikunj[m]> K-ballo: hkaiser really curious why std::span is introduced in the C++20 standard. What was std::array and std::vector missing? For one, I can think of initializing vector from a c-style array. Two, compile time initialization of elements (But constexpr tuple can do compile time initialization, then why this?)

21:52 <k-ballo[m]> span isn't a container

21:53 <gnikunj[m]> https://en.cppreference.com/w/cpp/container/span is this wrong?

21:55 <gnikunj[m]> k-ballo[m]: what exactly is std::span's intended use case?

21:56 <k-ballo[m]> a view over a continuous range

21:56 <k-ballo[m]> it's not wrong, because it doesn't say its a container

21:57 <gnikunj[m]> sure, but why do we need a view over an already existing array?

21:57 <gnikunj[m]> the array is a continuous range as well. What is it's exact use?

21:58 <k-ballo[m]> same as any other view

21:58 <k-ballo[m]> you get to look at it

21:58 <gnikunj[m]> aah, is it a helper for ranges?

21:58 <k-ballo[m]> think string_view, but general purpose

21:59 <gnikunj[m]> got it!

21:59 <gnikunj[m]> I got confused from https://github.com/kokkos/mdspan proposal

22:00 <gnikunj[m]> it should not be called mdspan in case it gets accepted in C++23

22:01 <k-ballo[m]> why not? it's a multi dimensional span