5 ms·

Novice question here: Applications that care about performance already do things like buffered reads, to minimize the overhead of system calls. Is there much va

Novice question here: Applications that care about performance already do things like buffered reads, to minimize the overhead of system calls. Is there much value to optimizing read() in that case? Are there other system calls that are harder for applications to amortize?

kragen 7y ago
Part of the value of reducing system call overhead is that it reduces the need to buffer reads; one of Massalin's key use cases was building a real-time audio processing system (on I think a 40-MHz dual-processor 68020 workstation) out of shell pipelines, for example to simulate what her voice would sound like after her gender transition, and real-time audio processing is terrible when there's a lot of buffering introducing latency. Only up to a few milliseconds is acceptable over the whole pipeline. On my Linux laptop the read() overhead is only about 300 ns, but lmbench says the pipe latency is 19000 ns, which adds up fast. There's also the overall complexity cost: by pushing complexity into dozens of libraries and thousands of applications to compensate for unnecessary inefficiency in the kernel, the system can become more complex — harder to debug and harder to optimize — than if you just bite the bullet and optimize the kernel. And even then, you don't get back all the performance you lost — on Synthesis, unbuffered reads were actually faster than buffered reads on other operating systems, because you could avoid the extra copy through the userland buffer! Assuming it's possible to optimize the kernel that much, of course. On a Netburst Pentium IV, you're fucked, and it still remains to be seen how bad the Intel speculative execution disaster ends up being.
vidarh 7y ago
You'd think so, but it's crazy how much code does not minimize system calls at all. Things like read() to read the length of a string followed by a second read() to read the string (hopefully after sanity checks..) is rife. "strace -c" is my favorite first stop when something looks slower than it should, and it's just insanely frustrating how often it reveals poorly written code.

kragen 7y ago

Part of the value of reducing system call overhead is that it reduces the need to buffer reads; one of Massalin's key use cases was building a real-time audio processing system (on I think a 40-MHz dual-processor 68020 workstation) out of shell pipelines, for example to simulate what her voice would sound like after her gender transition, and real-time audio processing is terrible when there's a lot of buffering introducing latency. Only up to a few milliseconds is acceptable over the whole pipeline. On my Linux laptop the read() overhead is only about 300 ns, but lmbench says the pipe latency is 19000 ns, which adds up fast. There's also the overall complexity cost: by pushing complexity into dozens of libraries and thousands of applications to compensate for unnecessary inefficiency in the kernel, the system can become more complex — harder to debug and harder to optimize — than if you just bite the bullet and optimize the kernel. And even then, you don't get back all the performance you lost — on Synthesis, unbuffered reads were actually faster than buffered reads on other operating systems, because you could avoid the extra copy through the userland buffer! Assuming it's possible to optimize the kernel that much, of course. On a Netburst Pentium IV, you're fucked, and it still remains to be seen how bad the Intel speculative execution disaster ends up being.

vidarh 7y ago

You'd think so, but it's crazy how much code does not minimize system calls at all. Things like read() to read the length of a string followed by a second read() to read the string (hopefully after sanity checks..) is rife. "strace -c" is my favorite first stop when something looks slower than it should, and it's just insanely frustrating how often it reveals poorly written code.