Am Mi., 28. Okt. 2020 um 20:11 Uhr schrieb Tom M. via fluid-dev <fluid-dev@nongnu.org>: > 1. The samplecache is guarded by a mutex that prevents naïve > parallelization.
Yes, and that is a difficult lock to remove, I think. But as a quick check for a possible speedup factor with parallel loading, your branch is a good test. > 2. If we relax that mutex we get a strange race condition, resulting in > various failed sample decodings. That is because all threads use the same file pointer and thrash each others file position all the time. If you modify the vorbis loader code so that it opens a new file pointer before doing the virio stuff, it loads without errors. Here's the comparison... Current master: $ time ./fluidsynth -a file MuseScore_General.sf3 -i real 0m6,689s user 0m6,381s sys 0m0,185s parallelize-sf3-loading (with separate file per worker fix): $ time ./fluidsynth -a file MuseScore_General.sf3 -i real 0m2,795s user 0m9,512s sys 0m0,260s When using the parallel loading my 4 cores are completely maxed out and I get around double the speed. Probably not enough speedup to remove the OPs problem, I guess? Cheers Marcus _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
