11 May
2009
11 May
'09
6:35 a.m.
What is the rationale for jackd requiring buffers to have number of
frames set to a power of 2? Could this be relaxed to perhaps a multiple
of 16, 32 or somesuch?
I have a few reasons for wanting to do so
a) Neither 128 nor 64 matches a samplerate of 96K and 1ms between USB
midi messages. 96 would.
b) CUDA (Nvidias gpgpu language) appears to have some magic regarding
192 threads that seems to work most fluently. This also happens to be a
multiple of 96 opening up for some programming efficiency advantages
when threadID equals [a multiple of] frame index.
c) Although certainly possible, 256 parallel "moog"-filters is a bit
overdoing it, no? IMHO, once a multichannel polysynth goes beyond 96
voices (in this case with two filters - one left, one right - per voice
== 192 threads) the experienced return of improved quality/complexity is
diminishing steeply, getting lost in the mix. I'd much rather spend more
clockcycles on, say post-processing of channels - or more room for a
simultanious video stream.
11 May
11 May
7:21 a.m.
On Mon, May 11, 2009 at 1:35 AM, Jens M Andreasen
<jens.andreasen(a)comhem.se> wrote:
What is the rationale for jackd requiring buffers to
have number of
frames set to a power of 2? Could this be relaxed to perhaps a multiple
of 16, 32 or somesuch?
I have a few reasons for wanting to do so
a) Neither 128 nor 64 matches a samplerate of 96K and 1ms between USB
midi messages. 96 would.
b) CUDA (Nvidias gpgpu language) appears to have some magic regarding
192 threads that seems to work most fluently. This also happens to be a
multiple of 96 opening up for some programming efficiency advantages
when threadID equals [a multiple of] frame index.
c) Although certainly possible, 256 parallel "moog"-filters is a bit
overdoing it, no? IMHO, once a multichannel polysynth goes beyond 96
voices (in this case with two filters - one left, one right - per voice
== 192 threads) the experienced return of improved quality/complexity is
diminishing steeply, getting lost in the mix. I'd much rather spend more
clockcycles on, say post-processing of channels - or more room for a
simultanious video stream.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Regarding the thread count issue, you are aware that buffer size,
number of threads used, and port count are completely different
things, right? There is no threading configuration available at with
jack that I know of, and jack does not directly interact with ladspa
plugins at all. You may know these things already, and maybe I just
misunderstand your question. Regarding the power of two buffer size
limitation, iirc that has to do with the efficient ring-buffer data
exchange implementation.
7:29 a.m.
On Mon, 2009-05-11 at 02:21 -0700, Justin Smith wrote:
Regarding the thread count issue ...
Wait, wait ... These are not pthreads but CUDA threads which are more
like vector elements in "warps". Intel talks about "fibers" when they
are describing their Larrabee - which might be a better terminology, at
least less confusing.
10:53 a.m.
On Mon, May 11, 2009 at 4:35 AM, Jens M Andreasen
<jens.andreasen(a)comhem.se> wrote:
What is the rationale for jackd requiring buffers to
have number of
frames set to a power of 2? Could this be relaxed to perhaps a multiple
of 16, 32 or somesuch?
I have a few reasons for wanting to do so
a) Neither 128 nor 64 matches a samplerate of 96K and 1ms between USB
midi messages. 96 would.
Even though USB devices are common, they are hardly the arbiter of
good hardware design for an audio interface.
The sample rate makes no difference to how often USB delivers audio
data - it always happens on the 1msec clock cycle whether the rate is
32kHz, 192kHz or anything else. Since 1msec doesn't translate to any
useful integer number at the most common SR's, its really not worth
paying that much attention to. 96kHz is not a very useful SR with most
USB interfaces (at present). If and when USB2 becomes more common, we
could revisit the issue. USB2, at least on linux, has a number of
other major hurdles to surmount before it becomes common for audio
devices.
However, notice that far more important from a performance perspective
is that power-of-2 buffer sizes permit buffers to be cache line
aligned, which as far as we know (its never been carefully measured)
greatly outweighs the kinds of concerns you are mentioning.
b) CUDA (Nvidias gpgpu language) appears to have some
magic regarding
192 threads that seems to work most fluently. This also happens to be a
multiple of 96 opening up for some programming efficiency advantages
when threadID equals [a multiple of] frame index.
this has absolutely nothing to do with JACK.
11:59 a.m.
On Mon, 2009-05-11 at 08:53 -0400, Paul Davis wrote:
However, notice that far more important from a
performance perspective
is that power-of-2 buffer sizes permit buffers to be cache line
aligned, which as far as we know (its never been carefully measured)
greatly outweighs the kinds of concerns you are mentioning.
a cache aligned buffer of 96 would easily fit in the same space as one
of 128, only with lower latency.
12:23 p.m.
On Mon, May 11, 2009 at 9:58 AM, Jens M Andreasen
<jens.andreasen(a)comhem.se> wrote:
On Mon, 2009-05-11 at 08:53 -0400, Paul Davis wrote:
I think you're missing the forest for the trees.
1) the question is now how to fit a single set of N samples into cache
memory. Its how to fit *all* the samples to be processed in a given
"cycle" into cache memory. Wasting 25% of cache memory for each buffer
isn't conducive to this.
2) CUDA and the rest are very, very powerful processing engines. But
they continue (for now) to be targetted towards tasks where
parallelism and not low latency is considered most important. You
simply can't get the data to and from the GPU fast enough for use in,
for example, live FX. This may change, and when it does it will be
quite an interesting development. But it has not changed yet, and I've
yet to see Nvidia or Intel talk about this goal in any way. They have
a *huge* number of use cases that can benefit from using a GPU already
(and the potential is really quite substantial, i think) - but there
is no incentive on their part to focus on a very niche case that wants
the processing power *and* wants very low latency.
However, notice that far more important from a
performance perspective
is that power-of-2 buffer sizes permit buffers to be cache line
aligned, which as far as we know (its never been carefully measured)
greatly outweighs the kinds of concerns you are mentioning.
a cache aligned buffer of 96 would easily fit in the same space as one
of 128, only with lower latency.
1:22 p.m.
On Mon, 2009-05-11 at 10:23 -0400, Paul Davis wrote:
1) the question is now how to fit a single set of N
samples into cache
memory. Its how to fit *all* the samples to be processed in a given
"cycle" into cache memory. Wasting 25% of cache memory for each buffer
isn't conducive to this.
If 96 frames are enough for stability (and say 64 isn't), then sample 96
- 127 in a 128 frame buffer are a waste of memory anyway and only adds
to latency.
It may even be so that a set of shorter buffers that are only partially
aligned - but allocated as one continous area - may have a greater
chance of fitting into available cache, without trashing other important
data.
1:29 p.m.
On Mon, May 11, 2009 at 11:21 AM, Jens M Andreasen
<jens.andreasen(a)comhem.se> wrote:
On Mon, 2009-05-11 at 10:23 -0400, Paul Davis wrote:
sometimes there is a tradeoff between latency and CPU cycles. live
recording often tilts towards less CPU cycles and more latency.
1) the question is now how to fit a single set of
N samples into cache
memory. Its how to fit *all* the samples to be processed in a given
"cycle" into cache memory. Wasting 25% of cache memory for each buffer
isn't conducive to this.
If 96 frames are enough for stability (and say 64 isn't), then sample 96
- 127 in a 128 frame buffer are a waste of memory anyway and only adds
to latency. It may even be so that a set of shorter buffers that
are only partially
aligned - but allocated as one continous area - may have a greater
chance of fitting into available cache, without trashing other important
data.
the point of making things cache aligned relates to SSE(2). the point
of making them fit in the cache relates to overall throughput. not
quite the same thing.
1:54 p.m.
On Mon, 2009-05-11 at 11:43 -0400, Paul Davis wrote:
On Mon, May 11, 2009 at 11:37 AM, Jens M Andreasen
<jens.andreasen(a)comhem.se> wrote:
That buffers of 96 floats are perfectly aligned with SSE although
perhaps not with the cacheline.
If it indeed is SSE that gives the performance advantage rather than the
caheline, then the rules can be relaxed from powers of 2 to multiples of
4 (floats).
On Mon, 2009-05-11 at 11:29 -0400, Paul Davis wrote:
which changes my point in what way?
the point of making things cache aligned relates to SSE(2).
SSE wants 128 bit alignment not 1024.
3 p.m.
On Mon, 2009-05-11 at 17:54 +0200, Jens M Andreasen wrote:
If it indeed is SSE that gives the performance
advantage rather than the
caheline, then the rules can be relaxed from powers of 2 to multiples of
4 (floats).
Make that multiples of 16, and the buffer will be aligned with the
caheline as well (for P4 - Core2.) So buffersizes of 48, 96 and why not
192 should be quite OK.
3:49 p.m.
Jens M Andreasen wrote:
What is the rationale for jackd requiring buffers to
have number of
frames set to a power of 2? Could this be relaxed to perhaps a multiple
of 16, 32 or somesuch?
SSE optimizations require, for performance reasons, that buffers are
128-bit aligned. SSE is really slow on non-aligned access and due to
rather small buffers cannot catch up in the performance after getting up
to aligned address. Size itself doesn't have to be anything specific,
but anything which is not multiple of 4 would also cause slow down.
Having some pad bytes (if possible) thus makes it possible to work
around this limitation.
By disabling SIMD optimizations this restriction goes away with some
performance penalty.
- Jussi
3:53 p.m.
Jens M Andreasen wrote:
like vector elements in "warps". Intel talks
about "fibers" when they
are describing their Larrabee - which might be a better terminology, at
least less confusing.
While on Windows API, fiber is a 'thread' or scheduling entity who's
execution is not controlled by kernel, but by application.
http://msdn.microsoft.com/en-us/library/ms682661(VS.85).aspx
I would just speak about hardware threads or execution pipelines.
- Jussi
3:55 p.m.
Paul Davis wrote:
However, notice that far more important from a
performance perspective
is that power-of-2 buffer sizes permit buffers to be cache line
aligned, which as far as we know (its never been carefully measured)
greatly outweighs the kinds of concerns you are mentioning.
I did some testing on this in past when developing bunch on SSE
routines. The performance difference was around 2x.
- Jussi
6:33 p.m.
Jens M Andreasen wrote:
Sorry for not being specific, in the test it was SSE unaligned vs
256-bit aligned. :)
For 96 float buffers it thus shouldn't be a problem. Something like 97
would be...
- Jussi
I did some
testing on this in past when developing bunch on SSE
routines. The performance difference was around 2x.
What was 2x and compared to what? Unaligned SSE or exact cacheline
match?
5487
days inactive
5487
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
4 participants
participants (4)
-
Jens M Andreasen -
Jussi Laako -
Justin Smith -
Paul Davis