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. --
