4 ms·

Everything you mentioned is irrelevant in the context of unbuffered IO. The majority of time is going to be spent on system calls, context switching, and signal

Everything you mentioned is irrelevant in the context of unbuffered IO. The majority of time is going to be spent on system calls, context switching, and signal handling / checking, and waiting for hardware interrupts to fire and handling them. Also there is a lot more then mentioning cpu cache as this is very generic term. which part of the cpu cache are you talking about? instruction cache? data cache? And why do you have think they matter in this context?

bcrl 5y ago
My comments are perfectly relevant. Using read() and write() still uses buffers, it's just that those buffers happen to be in the kernel. read() and write() still do the kernel's form of memcpy() internally. Truly unbuffered I/O from the kernel's perspective is direct I/O that DMAs data directly into application provided memory. It is important to note that every time buffered I/O is used, it copies data through buffers, and touching those buffers means the memory used for those buffers being touched clearly has to be pulled into the CPU's L1 data cache. In some cases the extra cache traffic for those buffers degrades performance. Instruction caches are relevant to some workloads, but are clearly not what I was referring to since data doesn't go through the instruction cache. glibc further complicates the matter by using mmap() in some cases to directly map the kernel's buffers for data (the page cache in the context of Linux) into userspace. This avoids some of the downsides of buffered I/O by avoiding one of the copies at the expense of page fault overhead. Sometimes it's better for the application itself to use mmap() directly. Direct use of read() and write() makes sense for some applications, especially when dealing with larger chunks of data. Saying unbuffered I/O is bad is a gross oversimplification of the reality when writing high performance applications. Like everything in programming, it's a good rule of thumb, but there is definitely an asterisk next to it.

bcrl 5y ago

My comments are perfectly relevant. Using read() and write() still uses buffers, it's just that those buffers happen to be in the kernel. read() and write() still do the kernel's form of memcpy() internally. Truly unbuffered I/O from the kernel's perspective is direct I/O that DMAs data directly into application provided memory. It is important to note that every time buffered I/O is used, it copies data through buffers, and touching those buffers means the memory used for those buffers being touched clearly has to be pulled into the CPU's L1 data cache. In some cases the extra cache traffic for those buffers degrades performance. Instruction caches are relevant to some workloads, but are clearly not what I was referring to since data doesn't go through the instruction cache. glibc further complicates the matter by using mmap() in some cases to directly map the kernel's buffers for data (the page cache in the context of Linux) into userspace. This avoids some of the downsides of buffered I/O by avoiding one of the copies at the expense of page fault overhead. Sometimes it's better for the application itself to use mmap() directly. Direct use of read() and write() makes sense for some applications, especially when dealing with larger chunks of data. Saying unbuffered I/O is bad is a gross oversimplification of the reality when writing high performance applications. Like everything in programming, it's a good rule of thumb, but there is definitely an asterisk next to it.