On 30/10/20 5:42 am, Marcus Weseloh wrote:
Hi,
for anybody who wants to try the OpenMP parallel loading, I've just
pushed the fix for the vorbis load to use separate file pointers to
Toms branch here:
https://github.com/FluidSynth/fluidsynth/tree/parallelize-sf3-loading
Hamish, would be great to see how that performs on your 6 core
machine. Like I said, I get a little over twice the speed on four
cores.
And the loaded font does actually play a test midi file... so at least
it's not completely broken :-)
Beautiful! Over 6 times faster. Here's master:
./fluidsynth -i -a file *.sf3 9.13s user 0.17s system 99% cpu 9.298 total
And here's the parallel version:
./fluidsynth -i -a file *.sf3 15.22s user 0.38s system 1105% cpu 1.411
total
Sounds good too.
To answer your question, is it enough? Yes, but now that I am loading in
the background I will keep doing that too. Here's what I have done over
time.
1. Block while load soundfonts. I used to use 1xSF2, 1xSF3 so is was ~5
seconds.
2. Start loading soundfonts (2xSF3) in a background thread (~10
seconds), do other initialisations, wait for soundfonts to finish,
unblock application.
3. Start loading soundfonts, do other initialisation, unblock
application, and only block again if the user tries to use the synth
before loading is finished (not common).
So now I have #3 it's not really important for me to speed up the
loading any further, but I posted this just for interest's sake and I'm
glad it's generated some discussion, and I think other applications can
benefit too. In order to get the best out of modern CPUs we have to use
more threads as the cores aren't getting much faster.
cheers
Hamish
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
