Re: [fluid-dev] Parallelize rendering using openMP

[Ceresa Jean-Jacques]

Hi,

 

>Maybe it would also be worthwhile to look at the chrous and reverb code. At least on my machine and with the setup I use, the effects take up a large proportion of processing time. And that processing is always single threaded...

 

Effects processing (reverb, chorus) are executed after the processing of all voices rendering (which is single /multi-thread). Effects is only single threaded, because they are common to all voices.

For information internal code in the actual reverb (freeverb: //ccrma.stanford.edu/~jos/pasp/Freeverb.html)  is the processing of:  8 combs filters + 8 first order low pass filters + 4 all-pass filters + stereo unit. When executed on a cpu with math coprocessor the whole reverb load is equivalent to: 4,1 x 1 voice load.

Chorus is:  N time variant delays lines (modulated by LFO). It is special as the cpu load depends of the number of delay lines chosen.

 

>At least on my machine and with the setup I use, the effects take up a large proportion of processing time.

Please at the occasion, if the hardware you use is dedicated to a stand alone synthesizer, could you run the profile commands and return the results (with CPU model) ?.

 

# for reverb / chorus performance measurement

>prof_set_notes 100  # must be set so that you get "total(%)" result never above 100%

>chorus on

>reverb on

>prof_start 5 1000

 

cheers.

jjc

 

 

 

> Message du 16/04/18 10:34
> De : "Marcus Weseloh" <address@hidden>
> A : "FluidSynth mailing list" <address@hidden>
> Copie à :
> Objet : Re: [fluid-dev] Parallelize rendering using openMP
>
>

Hi Tom,
>
> 2018-04-14 17:58 GMT+02:00 Tom M. <address@hidden>:
> > 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.
>
> Well, assuming you are using "normal" MIDI files as input and test with that, the advantages of parallel rending are bound to be much smaller than with an artificial test that tests extreme cases, I think.
>  
> > 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.
>
> Please don't get me wrong, I also think that it's worth evaluating a better parallel rendering implementation. So I am all for your approach of just testing it out. I was just curious if you had done more measurements on synchronization overhead.
>  
> > 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.
>
>

That sounds good. Maybe it would also be worthwhile to look at the chrous and reverb code. At least on my machine and with the setup I use, the effects take up a large proportion of processing time. And that processing is always single threaded...
>
> Cheers,
>
>     Marcus
>

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev