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