Hi,

> (but it is still limited to 256 x 16  notes !)

Houps , i must correct me. Please read 128 as ofc there are only 128 notes 
maximum per MIDI channel.

jjc

> Message du 15/04/18 00:00
> De : "Ceresa Jean-Jacques" 
> A : "FluidSynthmailinglist" 
> Copie à : 
> Objet : Re: [fluid-dev] Parallelize rendering using openMP
> 
>
> Thanks for yours awswers

>  

> >Apparently the soundfonts I used were not polyphonic enough

> >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.

>  

> Effectivelly, your machine is fast and in this case playing MIDI file to 
> simulate a notes (voices) generator isn't not efficient. This is why the 
> profiling interface have is own notes generator (but it is still limited to 
> 256 x 16  notes !).

> The most important is that fluidsynth are able to play constant number of 
> voices during measurement. This gives consecutives measurement the same cpu 
> load result. This makes any future performances measurements easily much more 
> predictive.

> Note:During my experiment, initially i have noticed that result between 
> consecutives measurement was not constant. Quickly, i realized that a 
> backgroud process was running. The job of this process was to economize 
> energy . It was doing this by stealing cpu cycle!. Of course any performance 
> measurement aren' possible with this kind of jobs or services running 
> silently behind the scene.

>  

> >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.

> Interresting. Looking the code (in the past) i have noticed that a lot of 
> things perhaps could be enhanced arround the following subject:

> 1) avoiding mutual access to the "active list of voices" between  "primary 
> tasks" and the pool of "extra tasks".

>    - breaking the unique list in local list for each task.

>    - load balancing (same number of voices in each local list).

> 2) optimizing mixing of buffers between "primary" task and "extra task" (to 
> avoid actual possible synchronization overhead domination).

> 3) optimizing fluid_cond_signal(), fluid_cond_wait() each time the associated 
> mutex is pointless.

> Of course all this is easier to say than to do :).

> jjc

> Message du 14/04/18 17:58
> De : "Tom M." 
> A : fluid-dev@nongnu.org
> Copie à : 
> Objet : Re: [fluid-dev] Parallelize rendering using openMP
> 
> 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
> 
> 
> _______________________________________________
> 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

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

Reply via email to