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" > A : "FluidSynth mailing list" > Copie à : > Objet : Re: [fluid-dev] Parallelize rendering using openMP > > Hi Tom, > > 2018-04-14 17:58 GMT+02:00 Tom M. : > > 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 fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
