[fluid-dev] Re: Multi core support committed and improved

[David Henningsson]

address@hidden skrev:
> After implementing a mostly lock-less version of the multi-core support
> and optimizing it nicely (locks are only held for thread
> synchronization, which occurs once per fluid_synth_one_block), 

And only if cpucores > 1, I hope?

> I went
> ahead and committed my changes.  Basically all the voices are
> synthesized to their own dedicated audio buffers, which turns out to be
> not all that much data (FLUID_BUFSIZE * 256 for polyphony=256 is 64K for
> 32 bit float data) and simplified the logic greatly (no need to handle
> buffer starvation).  

Weren't they already using separate buffers...?

> I tested it on my little brother's core duo laptop and saw -F fast
> rendering increases of anywhere from 11-25%.  A decrease of 25% in
> render time doesn't seem all that bad, if you consider that the maximum
> theoretical reduction of 2 CPUs would be 50%.  I imagine some of the
> other code paths (reverb/chorus, etc) are probably rather significant
> and could perhaps also benefit from multi-cores (perhaps do reverb and
> chorus separately or something).

Perhaps synchronizing caches are also something that will slow down
performance. 64K (and usually less) is smaller than the L2 cache (and
even L1 cache on some CPUs), so a single CPU core would keep it in cache.

> I also added audio.realtime=yes/no, midi.realtime=yes/no,
> audio.realtime-prio=1-99 and midi.realtime-prio=1-99 as I discussed
> before.  

Perhaps it is important to get good defaults here - we should try a few
steps below standard for the JACK driver, and midi drivers should be a
few steps below the audio drivers, right?

> The core threads take advantage of this, to try and be the same
> priority as the audio threads.  The possible priority inconsistency is
> still an issue for programs embedding FluidSynth though, but it would
> still work, just perhaps not optimally.

I read about RealTimeKit the other day, seems like it could be a
fallback if the user has not configured rtprio in limits.conf. It'll
make us depend on dbus though. See

http://lalists.stanford.edu/lad/2009/06/0191.html

Perhaps something to consider.

> A couple of bug fixes got committed too, which I caught with valgrind.

That's great! I thought of doing something similar but never got around
doing it.

> I'd like to hear of other user's experiences with the new multi core
> support, 

I've been a bit busy this week but hopefully I will get around and test
it soon.

Keep up the good work!

// David