2018-04-14 17:58 GMT+02:00 Tom M. <address@hidden
> 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...