17 Aug
2009
17 Aug
'09
2:21 a.m.
I'm trying to squeeze the last little bit of juice out of my EEE.
The CPU I have is this:
http://restivo.org/projects/eee/cpu.txt
This nifty script at http://www.pixelbeat.org/scripts/gcccpuopt , says I should use
"-march=core2 -mtune=pentium -mfpmath=sse"
However, the Gentoo people (who I take to be an -funrollloops authority on performance
tuning), say I should "-march=core2 -mtune=generic -fomit-frame-pointer -pipe".
And then there is -march=native which many say is just easier and faster. And others
recommend putting "-msse2" and other such things.
What say you-all?
I want to maximize the efficiency of, in particular, LinuxSampler, CALF/CAPS/TAP/GUTARIX
plugins, AZR3, and Fluidsynth, but keep them super-stable as they have been.
Thanks!
-ken
17 Aug
17 Aug
8:29 a.m.
On Mon, Aug 17, 2009 at 5:21 AM, Ken Restivo<ken(a)restivo.org> wrote:
I'm trying to squeeze the last little bit of juice
out of my EEE.
The CPU I have is this:
http://restivo.org/projects/eee/cpu.txt
This nifty script at http://www.pixelbeat.org/scripts/gcccpuopt , says I should use
"-march=core2 -mtune=pentium -mfpmath=sse"
However, the Gentoo people (who I take to be an -funrollloops authority on performance
tuning), say I should "-march=core2 -mtune=generic -fomit-frame-pointer -pipe".
And then there is -march=native which many say is just easier and faster. And others
recommend putting "-msse2" and other such things.
What say you-all?
If you want the fastest possible floating point code, then you
probably want something like:
-march=core2 -msse -msse2 -mfpmath=sse -ffast-math -fomit-frame-pointer -O3
... but with caveats.
Discussion:
Supplying -ffast-math causes the use of non-IEEE-compliant math
functions. Among other things, this screws up any code that
explicitly deals with infinity or NaN values or signed zeroes, and
makes assumptions about properties like associativity for the purposes
of optimisation which may not be true in the floating-point world. In
other words, it can give you the wrong results. In _most_ cases,
audio applications are fine with it, but you need to be aware that it
can be problematic.
However, -ffast-math in combination with -mfpmath-sse has the very
nice quality that it enables denormal flush to zero throughout, thus
avoiding denormal slowdowns in filters and the like. It's also much
faster for some of the apparently simple operations like floor() that
are surprisingly slow in IEEE compliant mode.
It might be interesting to know what the authors of the programs
you're trying to optimise thought about the use of -ffast-math...
Perhaps you could compile them both ways and compare the output.
-fomit-frame-pointer is pretty much guaranteed to make things
marginally faster but harder to debug. It won't break anything and it
won't make any huge improvements.
-O3 rather than -O2 because it enables -ftree-vectorize, which does
some limited auto-vectorization of loops for things like
floating-point copy into SSE operations. This doesn't always do
anything (depends on the code, obviously) but sometimes it makes a
significant difference, for example it helps when compiling my Rubber
Band library. I've never yet seen any problems with the results, but
of course there's always an increased risk of running into
optimisation bugs the more optimisation you do. You can get
interesting (?) debug output about vectorization successes and
failures (mostly failures) with e.g. -ftree-vectorizer-verbose=2.
I would be slightly suspicious of anyone who recommends -pipe as an
optimisation -- it makes no difference to the resulting code, it just
makes compiling faster.
If you're using a 64-bit distro, then you can omit the options with
SSE in them (they're all enabled by default in 64-bit gcc).
Chris
8:44 a.m.
2009/8/17 Chris Cannam <cannam(a)all-day-breakfast.com>om>:
On Mon, Aug 17, 2009 at 5:21 AM, Ken
Restivo<ken(a)restivo.org> wrote:
On the SuperCollider dev list we're just having a conversation about
exactly this. NaNs are used in some cases for signalling, and since
compiling with -ffast-math implies -ffinite-math-only, that trashes
the NaN signalling. This combination seems OK though: "-ffast-math
-fno-finite-math-only". The moral of the story is probably that it
depends strongly on the app. Who knows if your chosen softwares make
use of NaNs and infinities? Hard to tell.
Dan
I'm trying to squeeze the last little bit of
juice out of my EEE.
The CPU I have is this:
http://restivo.org/projects/eee/cpu.txt
This nifty script at http://www.pixelbeat.org/scripts/gcccpuopt , says I should use
"-march=core2 -mtune=pentium -mfpmath=sse"
However, the Gentoo people (who I take to be an -funrollloops authority on performance
tuning), say I should "-march=core2 -mtune=generic -fomit-frame-pointer -pipe".
And then there is -march=native which many say is just easier and faster. And others
recommend putting "-msse2" and other such things.
What say you-all?
If you want the fastest possible floating point code, then you
probably want something like:
-march=core2 -msse -msse2 -mfpmath=sse -ffast-math -fomit-frame-pointer -O3
... but with caveats.
Discussion:
Supplying -ffast-math causes the use of non-IEEE-compliant math
functions. Among other things, this screws up any code that
explicitly deals with infinity or NaN values or signed zeroes, and
makes assumptions about properties like associativity for the purposes
of optimisation which may not be true in the floating-point world. In
other words, it can give you the wrong results. In _most_ cases,
audio applications are fine with it, but you need to be aware that it
can be problematic.
However, -ffast-math in combination with -mfpmath-sse has the very
nice quality that it enables denormal flush to zero throughout, thus
avoiding denormal slowdowns in filters and the like. It's also much
faster for some of the apparently simple operations like floor() that
are surprisingly slow in IEEE compliant mode.
It might be interesting to know what the authors of the programs
you're trying to optimise thought about the use of -ffast-math...
Perhaps you could compile them both ways and compare the output. -fomit-frame-pointer is pretty much guaranteed to make
things
marginally faster but harder to debug. It won't break anything and it
won't make any huge improvements.
-O3 rather than -O2 because it enables -ftree-vectorize, which does
some limited auto-vectorization of loops for things like
floating-point copy into SSE operations. This doesn't always do
anything (depends on the code, obviously) but sometimes it makes a
significant difference, for example it helps when compiling my Rubber
Band library. I've never yet seen any problems with the results, but
of course there's always an increased risk of running into
optimisation bugs the more optimisation you do. You can get
interesting (?) debug output about vectorization successes and
failures (mostly failures) with e.g. -ftree-vectorizer-verbose=2.
I would be slightly suspicious of anyone who recommends -pipe as an
optimisation -- it makes no difference to the resulting code, it just
makes compiling faster.
If you're using a 64-bit distro, then you can omit the options with
SSE in them (they're all enabled by default in 64-bit gcc).
Chris
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
--
http://www.mcld.co.uk
3:32 p.m.
On Mon, Aug 17, 2009 at 11:44:32AM +0100, Dan S wrote:
2009/8/17 Chris Cannam
<cannam(a)all-day-breakfast.com>om>:
> On Mon, Aug 17, 2009 at 5:21 AM, Ken Restivo<ken(a)restivo.org> wrote:
>> I'm trying to squeeze the last little bit of juice out of my EEE.
>>
>> The CPU I have is this:
>> http://restivo.org/projects/eee/cpu.txt
>>
>> This nifty script at http://www.pixelbeat.org/scripts/gcccpuopt , says I should
use "-march=core2 -mtune=pentium -mfpmath=sse"
>>
>> However, the Gentoo people (who I take to be an -funrollloops authority on
performance tuning), say I should "-march=core2 -mtune=generic -fomit-frame-pointer
-pipe".
>>
>> And then there is -march=native which many say is just easier and faster. And
others recommend putting "-msse2" and other such things.
>>
>> What say you-all?
>
> If you want the fastest possible floating point code, then you
> probably want something like:
>
> ?-march=core2 -msse -msse2 -mfpmath=sse -ffast-math -fomit-frame-pointer -O3
>
> ... but with caveats.
>
> Discussion:
>
> Supplying -ffast-math causes the use of non-IEEE-compliant math
> functions. ?Among other things, this screws up any code that
> explicitly deals with infinity or NaN values or signed zeroes, and
> makes assumptions about properties like associativity for the purposes
> of optimisation which may not be true in the floating-point world. ?In
> other words, it can give you the wrong results. ?In _most_ cases,
> audio applications are fine with it, but you need to be aware that it
> can be problematic.
Hmm. I did notice what appears to be a problem like that. With the
"-O2 -march=core2 -fomit-frame-pointer -pipe -march=core2 -mtune=pentium
-mfpmath=sse -ffast-math" options, all the audio apps were using a LOT less CPU via
top, but I ran into glitches in fluidsynth, when holding down a lot of notes and the
sustain pedal. But then, I haven't stress-tested this systematically. I am going to
have to build several different packages of these apps, each with several different flags,
and then try them very methodically, one by one, and see what happens.
In general, by far the biggest hogs are the LADSPA plugins. I use Caps VTS+Tonestack and
that of all of them is the biggest CPU users, with autowah as a close second.
>
> However, -ffast-math in combination with -mfpmath-sse has the very
> nice quality that it enables denormal flush to zero throughout, thus
> avoiding denormal slowdowns in filters and the like. ?It's also much
> faster for some of the apparently simple operations like floor() that
> are surprisingly slow in IEEE compliant mode.
>
> It might be interesting to know what the authors of the programs
> you're trying to optimise thought about the use of -ffast-math...
> Perhaps you could compile them both ways and compare the output.
I will do that. How would I compare the output though? Right now my "stress
test" is running a MIDI file that just holds down lots of notes in Fluidsynth, and
counting how many seconds it can tolerate that before I get that dreated
"CD-skipping" stuttering sound.
On the SuperCollider dev list we're just having a conversation about
exactly this. NaNs are used in some cases for signalling, and since
compiling with -ffast-math implies -ffinite-math-only, that trashes
the NaN signalling. This combination seems OK though: "-ffast-math
-fno-finite-math-only". The moral of the story is probably that it
depends strongly on the app. Who knows if your chosen softwares make
use of NaNs and infinities? Hard to tell.
In case anyone has any specific suggestions (or the authors are on this list), here are
the apps I am most interested in optimizing:
azr3-jack 1.0.2-1.1
caps 0.4.2-1
fluidsynth 1.0.8-1.1
jackd 0.116.1-4
libfluidsynth1 1.0.8-1.1
libgig6 3.3.0-1
libjack0 0.116.1-4
liblinuxsampler 1.0.0-1
linuxsampler 1.0.0-1
tap-plugins 0.7.0-2
terminatorx 3.82-7.2
Since CAPS Amp is one of the bigger CPU users, I'm remembering some years ago that
mtaht4 on IRC was working on re-doing all the CAPS or TAP code to optimize it. This was
before he and moved to the beach of Costa Rica, IIRC. Did he ever release that code
though? Maybe I should try it.
> -fomit-frame-pointer is pretty much guaranteed to make things
> marginally faster but harder to debug. ?It won't break anything and it
> won't make any huge improvements.
>
> -O3 rather than -O2 because it enables -ftree-vectorize, which does
> some limited auto-vectorization of loops for things like
> floating-point copy into SSE operations. ?This doesn't always do
> anything (depends on the code, obviously) but sometimes it makes a
> significant difference, for example it helps when compiling my Rubber
> Band library. ?I've never yet seen any problems with the results, but
> of course there's always an increased risk of running into
> optimisation bugs the more optimisation you do. ?You can get
> interesting (?) debug output about vectorization successes and
> failures (mostly failures) with e.g. -ftree-vectorizer-verbose=2.
>
> I would be slightly suspicious of anyone who recommends -pipe as an
> optimisation -- it makes no difference to the resulting code, it just
> makes compiling faster.
You have every reason to be suspicious; that "-pipe" was from Gentoo :-).
Obviously intended to mitigate the 3-day wait when typing "emerge @world". I
know it doesn't optimize, but this whole compiling process does go faster on my little
Atom when I use it, and it does no harm. So far LinuxSampler is the hugest compile time of
any of the apps, a second only to Ardour.
>
> If you're using a 64-bit distro, then you can omit the options with
> SSE in them (they're all enabled by default in 64-bit gcc).
>
>
This is a 32-bit Atom. I haven't tried optimizing the Dual Core2 64-bit, because it
hasn't been necessary.
Thanks for the detailed advice.
-ken
8:31 p.m.
New subject: Performance tuning audio apps -- Success!
Success!
I ended up using the following flags:
-msse -msse2 -mfpmath=sse -ffast-math -fomit-frame-pointer -O3 -fno-finite-math-only
-pipe
And all is well. I can run azr3, two fluidsynths, jackd, lashd, jackminimix, linuxsampler
(!), and four jack-rack instances with plugins from CAPS, TAP, CALF, and Fons's
autowah, and play them with responsiveness and no glitches... on a dinky little Atom
1.6Ghz netbook... while compiling software and running Firefox. Yay Linux!
Fluidsynth through jack-rack seems a lot more responsive too; less latency, even though
latency was already quite low. The exception here is LinuxSampler which has a little bit
of a lag, understandably.
Couple issues:
1) At Fons's suggestion, I had to add "LDFLAGS += -shared -nostartfiles" to
the debian/rules of CAPS 0.4.3 to get it to build.
2) Fluidsynth is acting very strangely. It "gets jealous". If I'm playing
another synth, which is demanding a lot of CPU, Fluidsynth throws a tantrum and sucks up
spikes of 80% CPU (according to top). AZR3 does this too sometimes. Why is that? Why would
a synth be sucking up tons of CPU even if no MIDI data is going into it? Is it getting
starved by the others.
3) Volume levels on AZR3 are sane now, for the first time ever, which suggests maybe it
had a denormal issue in there which one of those optimization flags might have fixed.
-ken
18 Aug
18 Aug
2:52 a.m.
New subject: Performance tuning audio apps -- Success!
Wow..I'm on a 1.6 Core Duo and I never got that lucky!
5:03 a.m.
New subject: Performance tuning audio apps -- Success!
On Tuesday 18 August 2009 01:30:30 Ken Restivo wrote:
Success!
I ended up using the following flags:
-msse -msse2 -mfpmath=sse -ffast-math -fomit-frame-pointer -O3
-fno-finite-math-only -pipe
And all is well. I can run azr3, two fluidsynths, jackd, lashd,
jackminimix, linuxsampler (!), and four jack-rack instances with plugins
from CAPS, TAP, CALF, and Fons's autowah, and play them with responsiveness
and no glitches... on a dinky little Atom 1.6Ghz netbook... while compiling
software and running Firefox. Yay Linux!
Wow! I will have to try some of this stuff on the next synth I compile.
Must EVERYTHING be compiled like this or just cpu-hogs like synths?
Hardware limitations? I have a pentium-III dinosaur.
Fluidsynth through jack-rack seems a lot more responsive too; less latency,
even though latency was already quite low. The exception here is
LinuxSampler which has a little bit of a lag, understandably.
Couple issues:
1) At Fons's suggestion, I had to add "LDFLAGS += -shared -nostartfiles"
to
the debian/rules of CAPS 0.4.3 to get it to build.
2) Fluidsynth is acting very strangely. It "gets jealous". If I'm playing
another synth, which is demanding a lot of CPU, Fluidsynth throws a tantrum
and sucks up spikes of 80% CPU (according to top). AZR3 does this too
sometimes. Why is that? Why would a synth be sucking up tons of CPU even if
no MIDI data is going into it? Is it getting starved by the others.
I had this
issue with most all synths, both on Windows (I paid good cash for
them!) and on Linux. Timidity is an example.
After discussions with the authors of the Windows synths: they must be
programmed to drop resources when idle. Otherwise, their code has no way of
knowing when it is "off-line" or idle. One of them, I forget which, did this
after we discussed it.
3) Volume levels on AZR3 are sane now, for the first time ever, which
suggests maybe it had a denormal issue in there which one of those
optimization flags might have fixed.
-ken
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
19 Aug
19 Aug
12:15 a.m.
New subject: Performance tuning audio apps -- Success!
On Tue, Aug 18, 2009 at 10:02:32AM +0300, David Baron wrote:
On Tuesday 18 August 2009 01:30:30 Ken Restivo wrote:
I only recompiled the programs I listed above (or somewhere in this thread, I don't
recall where). The big CPU pigs are the LADSPA plugins, by far, with CAPS AMP VTS being
the top of the list.
LinuxSampler is stunningly efficient. Fluidsynth is pretty good too, though it makes me
nervous for some reason. Both are playing samples rather than doing heavy math; it's
the LADSPA plugins that are crunching numbers.
-ken
Success!
I ended up using the following flags:
-msse -msse2 -mfpmath=sse -ffast-math -fomit-frame-pointer -O3
-fno-finite-math-only -pipe
And all is well. I can run azr3, two fluidsynths, jackd, lashd,
jackminimix, linuxsampler (!), and four jack-rack instances with plugins
from CAPS, TAP, CALF, and Fons's autowah, and play them with responsiveness
and no glitches... on a dinky little Atom 1.6Ghz netbook... while compiling
software and running Firefox. Yay Linux!
Wow! I will have to try some of this stuff on the next synth I compile.
Must EVERYTHING be compiled like this or just cpu-hogs like synths?
Hardware limitations? I have a pentium-III dinosaur.
Fluidsynth through jack-rack seems a lot more responsive too; less latency,
even though latency was already quite low. The exception here is
LinuxSampler which has a little bit of a lag, understandably.
Couple issues:
1) At Fons's suggestion, I had to add "LDFLAGS += -shared -nostartfiles"
to
the debian/rules of CAPS 0.4.3 to get it to build.
2) Fluidsynth is acting very strangely. It "gets jealous". If I'm playing
another synth, which is demanding a lot of CPU, Fluidsynth throws a tantrum
and sucks up spikes of 80% CPU (according to top). AZR3 does this too
sometimes. Why is that? Why would a synth be sucking up tons of CPU even if
no MIDI data is going into it? Is it getting starved by the others.
I had this
issue with most all synths, both on Windows (I paid good cash for
them!) and on Linux. Timidity is an example.
After discussions with the authors of the Windows synths: they must be
programmed to drop resources when idle. Otherwise, their code has no way of
knowing when it is "off-line" or idle. One of them, I forget which, did this
after we discussed it.
>
> 3) Volume levels on AZR3 are sane now, for the first time ever, which
> suggests maybe it had a denormal issue in there which one of those
> optimization flags might have fixed.
>
18 Aug
18 Aug
7:55 a.m.
On Mon, Aug 17, 2009 at 11:44 AM, Dan S<danstowell+lxau(a)gmail.com> wrote:
On the SuperCollider dev list we're just having a
conversation about
exactly this. NaNs are used in some cases for signalling, and since
compiling with -ffast-math implies -ffinite-math-only, that trashes
the NaN signalling. This combination seems OK though: "-ffast-math
-fno-finite-math-only".
That sounds like a good compromise for most purposes.
Chris
5622
days inactive
5623
days old
linux-audio-user@lists.linuxaudio.org
8 comments
5 participants
participants (5)
-
Chris Cannam -
Dan S -
David Baron -
Ken Restivo -
Ray Rashif