Hi Tom,
2018-04-20 21:56 GMT+02:00 Tom M. :
> I'm pretty much done implementing my ideas of an openMP parallelization.
> In short: I was not able to beat the current implementation.
Thank you very much for trying it out anyway! I think we still got quite a
few benefits from it. Better insight
I'm pretty much done implementing my ideas of an openMP parallelization. In
short: I was not able to beat the current implementation.
While a parallel logarithmic buffer reduction sounds nice indeed it has the
huge disadvantage that there needs to be a barrier waiting for all threads to
finish
Hi JJC,
2018-04-16 12:31 GMT+02:00 Ceresa Jean-Jacques <
jean-jacques.cer...@orange.fr>:
> >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
Hello,
>> do you think that it would be possible to implement this thing in addition
>> to existing code?
>
> Technically it would be possible, but having three implementations around
> would make this part completely unmaintainable. So no, sry. Why are you
> asking?
Just for portability.
Sin
uot;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 fr
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
> do you think that it would be possible to implement this thing in addition to
> existing code?
Technically it would be possible, but having three implementations around would
make this part completely unmaintainable. So no, sry. Why are you asking?
Tom
__
Hello,
do you think that it would be possible to implement this thing in addition to
existing code?
For example, something like:
#if THREADING_MODE_RVOICE == MODEL_SYNC_OPENMP3
...
#elif THREADING_MODE_RVOICE == MODEL_SYNC_THREAD
...
#else // THREADING_MODE_RVOICE == MODEL_SYNC_NONE
...
#endif
rs 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 :).
rse 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 usi
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 we
Hi Tom,
2018-04-11 20:59 GMT+02:00 Tom M. :
> I would like to rework fluidsynths parallel audio rendering. The current
> implementation is not very efficient, the synchronization overhead seems to
> dominate.
How did you come to the conclusion that the synchronization overhead
dominates? Did yo
Hi, Tom
>I would like to rework fluidsynths parallel audio rendering. The current
>implementation is not very efficient, the synchronization overhead seems to
>dominate. At least for me, most of the time only >one core is fully active.
I am surprised, you get only one core active most of
13 matches
Mail list logo
