Evaluate further multithreading improvements

Has this feature been discussed and generally agreed?

No.

Describe the solution you'd like

I think there are multiple places where there is a chance of further improving the multithreading behavior. These are things to investigate and benchmark, so there's no plan to modify this yet.

• The multithreading code currently hardcodes the number of threads to the number of visible processor cores. While this might be good for maximum throughput, it might be bad for predictability. In other words: There might be other tasks running on the same machine, e.g. kernel threads which require low latency (network I/O), other Jamulus instances or even other non-Jamulus server processes.
  • We should check if this default makes sense or if $NUM_CORES-1 would be better. Previous discussion: https://github.com/jamulussoftware/jamulus/pull/960#pullrequestreview-585007016 https://github.com/jamulussoftware/jamulus/pull/960#issuecomment-839836327 (If we are unsure whether touching the default is a good idea, we should leave it as-is to avoid causing problems for users)
  • We should look into making this configurable or document how to do it outside of Jamulus (cpuset?). At the very least we should log (on startup) how many threads will be used. Previous discussion: https://github.com/jamulussoftware/jamulus/pull/960#issuecomment-782758759 https://github.com/jamulussoftware/jamulus/pull/960#discussion_r632814416
• The amount of work which is put into the thread pool is pre-calculated both for decoding and encoding. In other words, on a 5 core machine with 21 clients, 5 threads will be used and blocks of work are generated as 5, 5, 5, 5, 1 (AFAIU).
  • This calculation is sub-optimal. Having one job which does way less than the others doesn't seem logical (of course, depending on client count and number of threads no perfectly balanced distribution is possible). For 21 clients and 5 threads, 5, 4, 4, 4, 4 might be better though.
  • This upfront calculation assumes that Jamulus has full insight into core performance behavior, while in practice it might not have this insight. Cores can be slower due to individual frequency scaling or due to parallel workload (network IO, system software). We don't have insight into the OS scheduler either. So unless the overhead of pThreadPool->enqueue() is huge (it requires a lock, so it may be relevant), I'd like to try using smaller blocks of work or dropping the upfront block planning altogether.
• Find out why a Jamulus server under high load stops responding to protocol messages. Is network I/O the next bottleneck? https://github.com/jamulussoftware/jamulus/blob/master/src/server.cpp#L1476-L1511 looks interesting.

cc'ing @menzels who last touched these parts and might have had good reasons for not going down these paths. :)
Also cc'ing @atsampson, @kraney and @softins who gave valuable input in #960.

Any insights to how benchmarking/profiling was previously done would also be helpful. I'll mainly focus on measuring decoding/mixing duration and jitter using this: https://github.com/jamulussoftware/jamulus/discussions/2440

Inizia in src/server.cpp, nella configurazione del numero di thread intorno alle righe 417-436, nella distribuzione del lavoro di decoding ed encoding intorno alle righe 802-823 e 878-896 e nella gestione del protocollo intorno alle righe 1476-1511. Usa l’approccio di benchmarking discusso in Discussion 2440 per misurare la durata e il jitter di decoding/mixing; il lavoro è completato quando vengono riportati i risultati e viene identificato un miglioramento concordato, oppure viene documentato il motivo per cui il comportamento attuale dovrebbe rimanere invariato.