Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 05/16/2010 12:34 PM, Nathan Meyers wrote: > If you know enough about your access patterns that you can do a better = > job of buffering than what standard libc logic does, you can choose to = > use the unbuffered I/O calls (read(2) and write(2)) instead of the=20 > buffered calls (fread(3), fwrite(3), and all the other stdio stuff). Bu= t=20 > you can destroy performance if you try this without really knowing what= =20 > you're doing. > =20 You are totally off base. This has nothing to do with the C language standard I/O. The "unbuffered I/O calls (read(2) and write(2))" are NOT unbuffered in Unix and Linux. The C standard library I/O creates additional buffers in the process' context. But in terms of the system calls, open(2), read(2), write(2), and ioctl(2) I/O is still fully buffered using kernel buffers. The kernel buffers are controlled by the various drivers. The real advantage of the kernel buffers is that even in random access I/O if you do a seek/read operation, if that data happens to be in a buffer you get it. Same for a random write. Certainly, I would agree if you know your access patterns you certainly have an advantage. Remember that files are read and written in blocks. If you know the disk geometry and the physical block sizes, as well as the usage patters, you can do better. --=20 Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |