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 01:05 PM, Jerry Feldman wrote: > 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 >> buffered calls (fread(3), fwrite(3), and all the other stdio stuff). But >> you can destroy performance if you try this without really knowing what >> you're doing. >> >> > 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. Sorry... yes, I'm addressing a different level of buffering. Consider me ingloriously run down between first and second. Nathan > 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. > > > > > > _______________________________________________ > Discuss mailing list > Discuss-mNDKBlG2WHs at public.gmane.org > http://lists.blu.org/mailman/listinfo/discuss >
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |