Hi Tom,
2018-04-14 17:58 GMT+02:00 Tom M. <tom.m...@googlemail.com>:
> 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
