I think I was the person who went through the code and tried to standardize things around 32 bit a couple of years ago. The performance reasoning for choosing one or the other had to do with a noticeable slowdown that was occurring due to type casting from mixing 32 with 64 bit. Having everything the same made a huge difference in terms of CPU utilization, but otherwise I couldn't tell a difference in performance between the two.
I chose 32 bit because at the time LADSPA and VST both used 32 bit interfaces, and since it was the type casting that was really killing performance, it was best to have everything as 32 bit. By the way, the biggest boost to performance came from eliminating the usage of PI from <math.h> and substituting a 32 bit version instead. That and switching to sinf and cosf. The casting that would take place in the interface to LADSPA and VST probably wouldn't be that big of a deal. It was the loops in the oscillators that were really chewing up the CPU. Danny ----- Original Message ---- From: Carmelo Piccione <[email protected]> To: Tommy Raz <[email protected]> Cc: [email protected] Sent: Mon, April 5, 2010 2:08:19 PM Subject: Re: [LMMS-devel] digital filters + internal sampleformat (float) Guys, While this isn't proof, doubles have long been just as efficient as floats, so I doubt you'll notice a significant performance difference (even on 10+ year old hardware). http://stackoverflow.com/questions/417568/float-vs-double-performance On Mon, Apr 5, 2010 at 2:05 PM, Tommy Raz <[email protected]> wrote: > Jonathan, > Problem with that line of thought is not everyone runs LMMS on today's system. > LMMS runs fairly well on my 1998 machine. I hope trade-offs between precision > and performance can be made optional, as has been done so far in many ways. > > LMMS does so much in real-time that it is very sensitive to performance. Even > with a new system, I can see myself taking it to the limit on how many tracks > and effects I can pile onto it. > > Allowing a CPU/cache hit for greater precision would not be such an issue if > LMMS was less real-time sensitive. For example, imagine if there was a > feature > to render selected tracks to a new audio track (muting the original ones) it > would allow a workflow to get around hitting the CPU wall. Tweeking gets a > bit > complicated, as one would delete rendered track, unmute source tracks, tweek, > and re-render to new audio track. But that would allow users to do huge > projects. I remember using this feature often when I used to write with > Mackie > Tracktion. > --Tommy > > From: Jonathan Aquilina <[email protected]> >>toby with the processing power we have now a days it shouldnt hit >>performance badly. especially since cache size and speeds are getting >>quicker > > On Thu, Apr 1, 2010 at 11:40 PM, Tobias Doerffel > <[email protected]>wrote: >>> ...Changing internal processing sample format to >>> double definitely would be nice if it does not introduce performance >>> regressions (whichI fear due to double data rate and thus less CPU cache >>> efficiency)... > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > LMMS-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lmms-devel > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ LMMS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ LMMS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel
