Re: [fluid-dev] Parallelize rendering using openMP

[Tom M.]

Thanks for the feedback so far.

> Please are you using a very fast machine ? did you ask to fluidsynth to play 
> sufficient number of notes ?

I'm on a Intel Core i5-3570K @ 3.40GHz. I tested several midi files that have 
instruments playing on all 16 channels. Apparently the soundfonts I used were 
not polyphonic enough, you're right. Using FluidR3_GM.sf2 the cpu load looks 
better, but I'm yet quite far from the "perfect" scalability that your 
profiling interface gives you JJC.

> How did you come to the conclusion that the synchronization overhead 
> dominates?

Admittedly this might be a wrong/premature conclusion based on my observations 
+ looking at the source code. I took a look at the callgraph generated with 
valgrind --tool=callgrind ./fluidsynth. Synchronization functions like 
g_mutex_lock() or g_cond_wait() are called quite often by 
fluid_mixer_thread_func(). Although it also reports to be not that expensive. 
Still I think it's worth evaluating what job openMP and other refactorings can 
do here. David Henningsson once told me that the parallel renderer was more 
like a (failed) experiment. So please see this current work as my little 
experiment.

> I do wonder though why OpenMP can do a better job than the current code.

openMP provides different scheduling strategies to process for loops. Also this 
restriction VOICES_PER_THREAD (==8) to avoid thread overhead seems quite magic 
to me (it probably worked well when David tested it, still, why is 8 the right 
number?). Overall I'm not sure whether openMP alone can do a better job. It 
definitely reduces complexity of the code. Additionally I want to revise the 
current implementation, like using a parallel logarithmic buffer reduction to 
mix audio between threads or rethinking data layout and memory accesses in 
general, hoping this makes it more efficient.

Tom