[linux-audio-dev] Re: [vst-plugins] Plugin server (Re: [vst-plugins] Re: [a bit OT] gcc as a cross compiler for VST?

Kjetil S. Matheussen k.s.matheussen at notam02.no
Sun Dec 8 13:34:01 UTC 2002


On Sun, 8 Dec 2002, Paul Davis wrote:

> Kjetil and i have been boring the VST crew to death. so we took it
> here :)
>
> >> because when running a real-time low-latency audio system, the cost of
> >> context switches is comparatively large. if you've got 1500usecs to
> >> process a chunk of audio data, and you spend 150usecs of it doing
> >> context switches (and the cost may be a lot greater if different tasks
> >> stomp over a lot of the cache), you've just reduced your effective
> >> processor power by 10%.
> >>
> >I dont believe you. I just did a simple context-switching/sockets
> >test after I sent the last mail. And for doing 2*1024*1024 context
> >syncronized switches between two programs, my old 750Mzh duron uses 2.78
> >seconds. That should about 1.3usecs per switch or something. By
>
> you didn't touch much of the cache, did you?

Eh. No. :)


> it doesn't matter how fast the actual switch is if each task wipes out
> the L1 and L2 cache, forcing a complete refill of the cache, reload of
> the TLB, etc. etc. the cost of a context switch is not just a register
> store+restore. the cost of it depends on what has happened since the
> last context switch.
>
> try your "simple context switch test" with a setup in which each task
> writes to about 256kB of memory.

Yupp, I see. I get a 7 percent penalty compaired to doing
the same just in one process.


> we measured this extensively on LAD a year or two ago. both myself and
> abramo and some others did lots of tests. we plotted lots of
> curves. the results were acceptable but not encouraging. yes, faster
> processors will decrease the time it takes to save and load the
> registers. but just as for much DSP code these days, other issues
> often dominate over raw CPU speed; the slow downs caused by the TLB
> being invalidated as a result of switching address spaces and the
> cache invalidation (for the same reason) are dramatic.

Going to dig into the discussion. This was very interesting.


> >I'm not talking about jack tasks, I'm talking about doing a simple
plug-in
> >task inside a standalone program, the way the vst server works.
>
> i don't understand how the vst server works. perhaps you can explain
> it.

Its just simple one to one process request/processing/answer. No mixing
or synchronising.


-- 





More information about the Linux-audio-dev mailing list