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

[josh]

Quoting David Henningsson <address@hidden>:
> 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?

Yes indeed.  If cpu-cores is 1 (the default), then it works as before  
(with the minor differences I mentioned previously).

> > 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...?

No.  Each voice was getting synthesized to a single static buffer and  
panned/mixed in fluid_voice_write() as well.  There is now a buffer  
allocated per voice, for the multi-core case only, which allows for  
the voices to easily get synthesized in parallel and mixed down at the  
end.

> 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.

Cache has always been a bit of a mystery to me, as far as how to take  
advantage of it and avoid pitfalls.  I think cachegrind is meant for  
cache analysis though, but I've never tried it.  Would probably be  
some good stuff to consider when we re-visit the optimization of  
FluidSynth.  I suspect there are likely some decent gains that can be  
made, especially if we try some SIMD stuff again.  It was attempted at  
one point by Markus Nentwig in the interpolation routines, but the  
minimal speed gains were disappointing.  There are some rather simple  
loops that could be easily converted to SIMD instructions though and  
some profiling should be done first to find out the problem areas.

> > 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?

Good idea.  I basically just left it almost the way it was before  
(same priority for audio: 90), but changed the MIDI thread to be lower  
(at 80, it was the same as the audio before).  Seems to me like having  
the MIDI the same SCHED_FIFO priority as the audio was a bad idea,  
since a continuous stream of MIDI events, could starve the audio  
process.  Seems like the audio thread starving the MIDI thread is a  
better course, since it would potentially throttle the incoming MIDI  
events too, though that is just a crude side effect.  At some point it  
would be nice to add some sort of auto polyphony setting, which will  
kill off voices if FluidSynth's CPU consumption goes above a certain  
threshold.  The voice kill algorithm needs some love too.

> > 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.

That sounds cool and I must say "Finally!"  Its been far too long that  
Linux developers have had to resort to nasty SCHED_FIFO stuff.  I'm  
all for adding support for it.  We don't need to make it a required  
dependency though, just a build time option.  Could fall back to the  
current method of things otherwise.

> > 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.

Cool.  I was kind of hoping for a little more performance out of it,  
but hey, if it can boost certain scenarios by 25%, that ain't all that  
bad :)  I think the FluidSynth code base has improved a lot from going  
that path as well (more modularized).  Once there is a bit of testing  
done, I'll be much more confident in FluidSynth's stability than in  
previous versions!

> Keep up the good work!
>
> // David

Thanks.  You too!

Josh