Questions about multi-threading

[wint3ria]

Hello, I have a couple of simple questions concerning multi-threading on the CPU for mitsuba/drjit

1. When setting a maximum number of threads with dj.set_thread_count(N) in python, it seems that DrJIT uses N + 1 threads for the computations. Is it intended? I did not see any docs/discussion on this, I may have missed something?

2. After "a while", CPU usage drops in Mitsuba during a run. I suspect that Mitsuba divides its workload at the begining of the execution and then launches a thread pool? May be the later phase of an execution run is dedicated to some lower performance result aggregation?

[wjakob]

Hi @wint3ria,

First, a quick question: are you using the LLVM variant of Mitsuba?

Regarding point 1: The dj.set_thread_count() call determines how many additional threads to allocate in a worker pool. But the main thread also participates in the computation, which explains the N+1 cores being active that you observed.

Regarding point 2: If a parallel rendering is not using parts of the CPU for an extended amount of time, then that is of course not a good thing. I don't have enough information from your description to assess why this might be happening. If it's a severe issue, then we could look into a reproduce if you have one.

[wint3ria]

Hello @wjakob

We are using the scalar mode, no LLVM

1. I may have missed it, but is there some docs about it?

2. It's not a severe issue. It's not even an issue at all, sorry for the misunderstanding. Most of the execution time of mitsuba has a very high CPU usage, no doubt about it. I'm talking about the very end of the workload. My question is more about the design of Mitsuba than an issue to report. What are the final steps in the process? Could it be that some worker threads finish first while the others are still working? Or is there a final step that requires less resources?

Thank you

[wint3ria]

I may write an example to illustrate point 2, but I will need some time for this in the following days

[wjakob]

In scalar mode, Mitsuba splits the image into sub-blocks and assigns them to processors. When one part of the image takes a lot of time to render, it can cause imbalance in the CPU load with only a few cores staying busy. You can ask Mitsuba to split the image into smaller blocks by specifying <integer name="block_size" value="..."/> to avoid that issue. The default is 32, you could use 8, 4, 2, or even 1. Having tiny blocks may add scheduling overhead for distributing so many work units.