Subject: Re: [linux-audio-dev] Re: costs of IPC
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue May 15 2001 - 18:27:57 EEST
>Wow! It's wonderful.
>
>I think that now we have proved that:
>- multiprocess approach is relatively cheap
>- whole object size has dramatic effect
*cough* *cough*
We've proved that:
- multiprocess approach is relatively cheap when used with small objects
So the question now becomes: what is the realistic size of the kinds
of components that would be in this system? Will they touch 5K, 15K,
50K or 150K or more of heap data? (Stack size is not likely to ever be
that large)
lets posit a system with 26 32 bit channels being used in a processing
network with no buffer reuse possible: at 64 frames per period, with
one input and one output buffer per channel thats 6kB just for the
audio data. Now lets assume 5 components, all with their own internal
buffers. Working on the "demanding end", lets assume that they have an
average of 2 internal buffers per channel, each using 32 bit data, and
that they process all 26 channels. Thats another 12kB or so for
internal buffers per component. with this in mind, it seems to me that
we might have footprints per component in the 20-40kB range, which
from these graphs looks like about a 5% hit. I've tried to add in some
vague numbers for "miscellaneous memory accesses", "instruction cache"
and so forth to get to this range.
if these numbers are accurate, then i'd say that a multiprocess model
will work OK for us. if they are on the small side, then there are
doubts about its usefulness. if they are on the large side, then we're
definitely OK.
comments?
i could try to benchmark or somehow measure ardour's typical memory
footprint during its handling of the AES callback ...
--p
This archive was generated by hypermail 2b28 : Tue May 15 2001 - 18:45:59 EEST