01:49 <diehlpk_work> hkaiser, The hpx-kokkos update to HPX 1.7 is strange

01:49 <diehlpk_work> It asks for kokkos 3.4.99 which is not released

01:49 <diehlpk_work> 3.4.01 is the lastest version

01:57 <hkaiser> diehlpk_work: it's probably based on kokkos master

07:38 <ms[m]> diehlpk_work: exactly that

07:38 <ms[m]> specifically, that branch that I have in the readme at the moment until it's merged into kokkos develop

08:15 <dkaratza[m]> <ms[m]> "could you describe what you..." <- alright, Im trying to fix the section "why hpx?"

08:17 <dkaratza[m]> this is what we have now and we said that we want the titles not to appear in the navigation bar

08:17 <dkaratza[m]> but if i just change the level of the titles it becomes like that

08:20 <dkaratza[m]> so just changing the level doesn't work because the titles keep appearing but a level lower

08:21 <dkaratza[m]> sorry for the late answer btw, its been really busy the last days

08:22 <ms[m]> dkaratza: ok, I see now

08:22 <ms[m]> so maybe we had different things in mind but I don't think we need to fully hide those subheadings

08:22 <ms[m]> we don't do that elsewhere after all

08:23 <ms[m]> at least what I was thinking is that for example everything after "governing principles..." could be a subsection of "governing principles..."

08:23 <ms[m]> then we'd be left with only headings on the first level

08:24 <ms[m]> I'm sure the text itself could also be restructured and shortened but that's a separate issue

08:24 <ms[m]> we can ask the others in the meeting later today

10:16 <dkaratza[m]> ms ok, so the suggestion is to add a title "governing principles" above these Already existing titles ?

10:16 <dkaratza[m]> <ms[m]> "we can ask the others in the..." <- Sure!

11:03 <ms[m]> dkaratza: yeah, something like that

11:03 <ms[m]> do you think that looks reasonable + like an improvement?

14:06 <pedro_barbosa[m]> s/functio/function/

14:07 <pedro_barbosa[m]> I was trying to copy the last line of a cube from the GPU to the Host but keep getting the error

14:07 <pedro_barbosa[m]> >"{what}: CudaError: out of memory at buffer:enqueue_read allocate host memory"

14:07 <pedro_barbosa[m]> And I'm not sure why but I think I'm trying to copy more data than what I think I'm going

14:08 <pedro_barbosa[m]> * I was trying to copy the 2nd line of a cube from the GPU to the Host but keep getting the error

14:08 <pedro_barbosa[m]> > "{what}: CudaError: out of memory at buffer:enqueue_read allocate host memory"

14:43 <dkaratza[m]> <ms[m]> "do you think that looks reasonab..." <- sure, makes sense!

18:34 <Guest16> Is there a way to have any hpx spawned thread execute some function before doing anything else?

18:35 <dkaratza[m]> do you know where i can find the hpx logo with the black letters?

18:35 <FunMiles> E.g. the MKL library can be switched per-thread to use a given number of threads. I'd like to call from HPX thread the routine that changes the number to set it to 1. But I don't want to do it more than once.

19:16 <dkaratza[m]> ms: also i think the conflict now is gone if you would like to check it. and i added the changes of the section "why hpx" as well

20:38 <FunMiles> Is there a way to have any hpx spawned thread execute some function before doing anything else? E.g. the MKL library can be switched per-thread to use a given number of threads. I'd like to call from HPX thread the routine that changes the number to set it to 1. But I don't want to do it more than once.

21:09 <hkaiser> pass your function(s) to a wrapper that sets it before executing the function

21:12 <FunMiles> @hkaiser In this case, it would happen for every function that I call, right? I don't know how costly the call the the MKL routine is, but I'd rather avoid it once it has been done. One option I thought of which is not cost-less at each call is to have a static thread-local variable that could take care of making the call the first time in its initialization. It still cost a few cycles, but probably less than the call to the

21:12 <FunMiles> MKL routine.

21:12 <hkaiser> https://gist.github.com/hkaiser/f04d1f0f08ec31a8962ce97c529c39ae

21:13 <hkaiser> well, then wrap it into a static function local variable initialization

21:14 <hkaiser> FunMiles: pls refresh the link above

21:16 <FunMiles> Yes that does work. As an alternative, would adding a customization point for HPX to make a user-given call at thread start and at thread end be easily done?

21:17 <FunMiles> OS thread I mean.

21:17 <hkaiser> for each created OS thread?

21:17 <hkaiser> or just on the main thread?

21:22 <FunMiles> For each OS thread.

21:22 <FunMiles> Just thinking of such cases, if the call was done at the start of each OS thread, I'd be set.

21:22 <FunMiles> Some people may have other uses too.

21:30 <hkaiser> FunMiles: you could simply create a thread_local instance of the init_once I posted

21:36 <FunMiles> thread_local instances are guaranteed to be created at thread start, I presume? What happens if a dynamic library is loaded that defines a thread_local variable? Will any thread started after guarantee their initialization?

21:41 <hkaiser> yes

21:41 <hkaiser> hmm, good point

21:53 <FunMiles> Some discussion on stack overflow mentions this from the standard:

21:53 <FunMiles> Dynamic initialization of a block-scope variable with static storage duration (6.7.1) or thread storage duration (6.7.2) is performed the first time control passes through its declaration; such a variable is considered initialized upon the completion of its initialization.

21:54 <hkaiser> FunMiles: I'd try it, but if the dll is loaded then the thread_local should kick in whenever a new thread is created

21:54 <hkaiser> nah, not function local scope

21:54 <hkaiser> create the thread_local at global scope

21:55 <FunMiles> I will experiment.

21:55 <FunMiles> The following rule may work for global storage:

21:55 <FunMiles> A variable with thread storage duration shall be initialized before its first odr-use (6.2) and, if constructed, shall be destroyed on thread exit.

21:55 <FunMiles> But it seems to say it has to be used somehow.

22:02 <hkaiser> FunMiles: no, global variables are initialized automatically

22:02 <hkaiser> so the constructor of a thread_local variable will run on thread start

22:05 <FunMiles> That's what I think. But I'm a bit wary of what a linker can do. If you put the definition of a static variable in a separate compilation unit, for example, it will not be linked in unless something in the compilation unit is referred to transitively from the main.

22:06 <FunMiles> Not a major issue though in this case.

22:15 <hkaiser> FunMiles: you can export the type

22:26 <FunMiles> Export as in "extern" declaration ? Would that guarantee link in? Is that on all system (Windows, Linux, Mac)?

22:43 <FunMiles> Does HPX run a thread continuously if after being started? If I have HPX in my code, I see a constant >80% CPU use yet nothing is being done. (REPL based executable and I am not running any command)