16 Sep
2002
16 Sep
'02
11:01 a.m.
i thought this was pretty insightful. vst-plugins has had a little
debate over whether or not VST should provide an integer sample
format. actually, not much of a debate. one person suggested it,
everybody else jumped on him. this post, however, is the most
detailed on why you should forget about thinking of float arithmetic
as slower than integer ...
--;p
------- Forwarded Message
Date: Sun, 15 Sep 2002 14:21:52 -0700
From: Vesa Norilo <vnorilo(a)siba.fi
To: <vst-plugins(a)lists.steinberg.net> (VST PlugIns)
Subject: [vst-plugins] Re: SDK buffers from host
Ah, good ol' Mike Abrash. But do yourself a favour and update your
knowledge: I'm pretty sure Mike has also done just that. BTW, I did
learn a huge amount from his Zen of Code Optimization, but almost
everything in it has become irrelevant by superscalar processing and
vector engines.
On AMD 3DNow, all floating point instructions take 2 cycles, and two of
them can be run in parallel, meaning that a total of 4 floating point
additions or multiplies can be executed in 2 clock cycles. These also
include sine, cosine, reciprocal and square approximations. Can you beat
that with integer asm?
To switch to the DIGEST mode, E-mail to
<vst-plugins-digest(a)lists.steinberg.net
To switch to the INDEX mode, E-mail to
<vst-plugins-index(a)lists.steinberg.net
Send administrative queries to postmaster(a)steinberg.de
------- End of Forwarded Message
i think you
are seriously and dramatically underestimating the
incredible benefits provided by a standardized
I haven't count cpu instruction
cycles recently. But last time
I did, the difference between floating point operations and
integer operation was from 15x to 100x speed difference. I
think though with the last few generation of cpu's they have
significantly narrowed the gap. Again in my very limited audio processing experience
so far
I'm finding that I can apply many of the same asm techniques.
And I know things are changing with new hardware I guess it's
possible in the future that floating with equal or, I don't know how,
but I suppose could even exceed int speeds.
Since I have AMD, I'm fluent with 3DNow and not SSE. But from what I
know, SSE is very similiar in functionality and power to 3DNow, and SSE2
offers even more capabilities.
To beat the vector engines, you would have to go MMX. This is for two
reasons: the saturating adds would eliminate the need of overflow
checking, and due to its SIMD nature it can match or outdo 3DNow/SSE.
Unless you are willing to drop to 16 bits (so that MMX can do 4
operations per instruction) it will not.
But when you get right down the heart of the matter,
the
computer really is only doing bit manipulations anyway -
floating point or int. The difference with IEEE floating is the fact
Which is why integer bit mask operations are still usable with floats,
making many neat tricks possible. Such as really fast logarithms, which
is again impossible with ints unless you use lookup tables (which you
don't want to do for 32 bit resolution)
that the cpu has to decode the register to get at the
exponent.
And that is going to add extra clock cycles. 2 sign bits have
So, if an instruction that performs two floating point multiplies costs
2 cycles (and can run parallel with another such), each floating point
multiply will consume 0.5 cycles. I don't really see any "extra cycles"
here. Do you?
Still the ideal speed approach is a flat bit array
with no decoding
and a big register, big enough to handle that largest number
you will ever have to deal with.
That's very untrue. Consider how much memory speeds are limiting
processing speed. Processing 32 bit floats is faster than 64 bit ints
largely for that reason. The optimal speed approach is not simple. It
has to do with optimizing memory for cost/benefit, optimizing cache and
processor for speed, and trying to strike a balance.
Consider floats as a hardware accelerated compression method that saves
memory bandwidth.
What's wide enough for audio processing (64
bit???, 128 bit???).
At some point need for an exponent simply disappears.
And the need for a 4GHz bus appears.
But you all are right. In reality it seems my lack of
experience
has jump up and bit me in the ass. And I was only looking at
things from my self-absorbed world of the plug-in I'm trying
to build to do some specific things I personally would like to
accomplish.
That's nice, but to recapitulate, don't really talk about optimization
before you know several SIMD sets by heart. Nowadays, that's mandatory.
For the above reasons under optimized assembly
language
conditions, I just don't see how float speeds can exceed int
speeds. But considering all of the other points you all have
brought up my suggestion seems to have been short-sited.
If your most recent knowledge is of x87 floating point asm, I understand
this perfectly. However, a speed and assembly enthusiast should keep
himself updated.
Best regards,
Vesa
#############################################################
This message is sent to you because you are subscribed to
the mailing list <vst-plugins(a)lists.steinberg.net>et>.
To unsubscribe, E-mail to: <vst-plugins-off(a)lists.steinberg.net
16 Sep
16 Sep
11:51 a.m.
On Mon, Sep 16, 2002 at 09:01:56 -0400, Paul Davis wrote:
i thought this was pretty insightful. vst-plugins has
had a little
debate over whether or not VST should provide an integer sample
format. actually, not much of a debate. one person suggested it,
Looking further ahead, the Itanium chip is incapable of native integer
multiplication, it converts to float, does the mult, and converts back.
I haven't read up on the 64bit AMD chip.
- Steve
11:56 a.m.
i thought this
was pretty insightful. vst-plugins has had a little
debate over whether or not VST should provide an integer sample
format. actually, not much of a debate. one person suggested it,
Looking further ahead, the Itanium chip is incapable of native integer
multiplication, it converts to float, does the mult, and converts back. 
3:51 p.m.
Paul Davis wrote:
i thought this was pretty insightful. vst-plugins has
had a little
debate over whether or not VST should provide an integer sample
format. actually, not much of a debate. one person suggested it,
everybody else jumped on him. this post, however, is the most
detailed on why you should forget about thinking of float arithmetic
as slower than integer ...
thanks paul, very interesting read indeed.
apropos, does somebody have pointers to enlightening resources,
code examples, anything about using 3Dnow/SSE/AltiVec with the gcc
suite? (please don't direct me to developer.intel.com, it's bloat
with a capital b).
tim
4:27 p.m.
On Mon, Sep 16, 2002 at 07:48:42 +0200, Tim Goetze wrote:
apropos, does somebody have pointers to enlightening
resources,
code examples, anything about using 3Dnow/SSE/AltiVec with the gcc
http://www.tommesani.com/SSE.html
Not gcc specific, but it will give you enough knowledge to make the intel
site intelligable.
If you find an equivalent site for 3DNow, please tell me!
- Steve
5:50 p.m.
Steve Harris wrote:
On Mon, Sep 16, 2002 at 07:48:42 +0200, Tim Goetze
wrote:
not equivalent, but it seems useful (got an extended example):
http://www.delphinus.demon.co.uk/spag/GCC_inline.html
and the 3dnow instruction set from:
http://www.amd.com/us-en/assets/content_type/ \
white_papers_and_tech_docs/21928.pdf
tim
apropos, does somebody have pointers to
enlightening resources,
code examples, anything about using 3Dnow/SSE/AltiVec with the gcc
http://www.tommesani.com/SSE.html
Not gcc specific, but it will give you enough knowledge to make the intel
site intelligable.
If you find an equivalent site for 3DNow, please tell me! 
17 Sep
17 Sep
7:52 a.m.
Hi all,
Steve wrote:
Tim already reported the AMD URL for the 3DNow Technology manual; I only
wanted to add that you can order an entire development CD from AMD for
free, containing quite a bunch of PDF files and other (more
Windows-related) programming material. Most (if not all) of the PDF
files are available on the web too, though.
Also, for getting started into Linux assembly programming,
http://www.linuxassembly.org looks like a nice site to me. Lots of links
and docs there.
Frank
PS: No, I haven't been doing any Linux assembly programming yet. I only
wondered every now and then how much performance one could get out of
some of the existing Linux soundapps if there were optimized versions of
such programs for certain CPUs.
apropos, does
somebody have pointers to enlightening resources,
code examples, anything about using 3Dnow/SSE/AltiVec with the gcc
http://www.tommesani.com/SSE.html
Not gcc specific, but it will give you enough knowledge to make the intel
site intelligable.
If you find an equivalent site for 3DNow, please tell me!
8:53 a.m.
On Tue, Sep 17, 2002 at 11:49:26 +0200, Frank Neumann wrote:
PS: No, I haven't been doing any Linux assembly
programming yet. I only
wondered every now and then how much performance one could get out of
some of the existing Linux soundapps if there were optimized versions of
such programs for certain CPUs.
From experimenting with the intel vecorising compiler I
would estimate you
could get 10-30% speed increase over gcc 2.96, for inner loops. I
think
gcc 3 does a better job, and maybe even does some 3dNow vectorisation?
the vector instructions (SSE, 3DNow and Altivec etc.) are mostly useful
when you have parallel streams to be processed identically, but you can
also get wins just by dropping in vec. instructions inplace of float
equivalents as they are sometimes less accruate, but faster and have
common branch avoiding instructions (eg. min and max).
I think there is some cost in switching between float mode and vector mode
(on x86, probably not powerpc), and I dont know how high that is.
- Steve
12:10 p.m.
Steve Harris wrote:
On Tue, Sep 17, 2002 at 11:49:26 +0200, Frank Neumann
wrote:
unfortunately there's nothing in
http://gcc.gnu.org/gcc-3.0/features.html that would suggest this.
PS: No, I haven't been doing any Linux
assembly programming yet. I only
wondered every now and then how much performance one could get out of
some of the existing Linux soundapps if there were optimized versions of
such programs for certain CPUs.
From experimenting with the intel vecorising
compiler I would estimate you
could get 10-30% speed increase over gcc 2.96, for
inner loops. I think
gcc 3 does a better job, and maybe even does some 3dNow vectorisation? the vector instructions (SSE, 3DNow and Altivec etc.)
are mostly useful
when you have parallel streams to be processed identically, but you can
also get wins just by dropping in vec. instructions inplace of float
equivalents as they are sometimes less accruate, but faster and have
common branch avoiding instructions (eg. min and max).
applying static gain seems to be a good candidate for SIMD even if
there's only one channel. needs some additional logic if buffers
aren't an integral multiple of the multiword size, though. finding
peaks without branching is very attractive, and a routine integrating
both would be very useful.
I think there is some cost in switching between float
mode and vector mode
(on x86, probably not powerpc), and I dont know how high that is.
i don't know either. it seems that all register content is lost, so
i think it is safe to assume it is internal to the cpu, and that the
cost will be fairly small. rdtsc will tell for sure. :)
with the need for [f]emms and gcc's crude inline assembly syntax, it
seems very desirable to isolate vectorized routines into .s sources
to me.
tim
12:17 p.m.
aren't an integral multiple of the multiword size,
though. finding
peaks without branching is very attractive, and a routine integrating
both would be very useful.
computing peaks and metering in general is the single most
computationally expensive thing that Ardour does (outside of certain
plugins). code to vectorize this would be a truly significant
contribution.
--p
12:58 p.m.
On Tue, Sep 17, 2002 at 04:07:58 +0200, Tim Goetze wrote:
unfortunately there's nothing in
http://gcc.gnu.org/gcc-3.0/features.html that would suggest this.
http://gcc.gnu.org/gcc-3.1/changes.html -mmmx -m3dnow etc. It can;t
vectgorise (by the sound of it) but it can do substituion and presumably
handle the register shifts?
applying static gain seems to be a good candidate for
SIMD even if
there's only one channel. needs some additional logic if buffers
Yes, also the normalised float -> integer conversion that is done in eg.
jacks output loop. It could be made branchless (and vectorised, unless you
are dithering).
with the need for [f]emms and gcc's crude inline
assembly syntax, it
seems very desirable to isolate vectorized routines into .s sources
to me.
Maybe, I've not done any serious inline assembler code in gcc. I'd be
interested in mucking in on a library of accelerated functions though,
it's an area I want to know more about.
- Steve
11:37 p.m.
On Mon, 16 Sep 2002 09:01:56 -0400
Paul Davis <pbd(a)op.net> wrote:
i thought this was pretty insightful. vst-plugins has
had a little
debate over whether or not VST should provide an integer sample
format. actually, not much of a debate. one person suggested it,
everybody else jumped on him. this post, however, is the most
detailed on why you should forget about thinking of float arithmetic
as slower than integer ...
--;p
I still use ints and fixed point because shifting and masking are
faster than fdiv and fmod.
As far as I know you cant do those instructions in one cycle using
floats, and I use them everywhere.
For my FM synth emulators I have fixed point iterators where the
integer part is shifted
and used as index to a sinetable and then the fractional part masked
for interpolation.
This amazingly beats using FSIN o my duron 850mhz, which not only
starts slowing down
when the float index is greater than PI/4, but also doesnt give good
results because
of the limited 23 bits mantisa. And yes, i tried using the fpu control
register to change
presicion to 32 bits.
Thats why my integer code is still many times faster than my floating
point code.
I allways start with floating point mixers to try out approaches and
then convert to fixed point
to gain a very considerable speed boost. Consider also that when
working with sample
data you usually have it in 16 bits signed format (uses less space
than a 32 bits floats)
Disk space and memory usage are vital when you are writing a sampler,
i'd hate it if my sample libs would take up twice as much.
Also saturated adds in MMX are awesome when layering/mixing many code
blocks.
For now, I dont see any reason to switch to floating point for my
stuff since facts show me what is
faster.
Juan Linietsky
18 Sep
18 Sep
7:01 a.m.
On Tue, Sep 17, 2002 at 10:35:40 -0300, Juan Linietsky wrote:
I still use ints and fixed point because shifting and
masking are
faster than fdiv and fmod.
As far as I know you cant do those instructions in one cycle using
floats, and I use them everywhere.
That would be in wavbetable phase though, everyone uses ints for those, for
one thing you get tuning problems if you use floats.
- Steve
8092
days inactive
8094
days old
linux-audio-dev@lists.linuxaudio.org
12 comments
5 participants
participants (5)
-
Frank Neumann -
Juan Linietsky -
Paul Davis -
Steve Harris -
Tim Goetze