dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/02/87)
>Which means that's not how pipes work. What I suggested was not having any >buffer in the pipe structure at all, but instead using the buffer provided >by the writer in its message. That way if the program used an 8K buffer, it >would automatically transfer 8K. If the program used 256 byte buffers, it >would transfer 256 bytes. The writer would always wait for the reader to read >the entire buffer, and data would be transferred straight from the writer >to the reader. This would save memory and time, at the cost of making the >writer wait on small writes. It's certainly worth looking into, anyway. >-- >-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter >-- U <--- not a copyrighted cartoon :-> No, you *WANT* to buffer data. The whole idea is to increase CPU throughput. For instance, lets say you are running an uncompress from a disk file. uncompress takes a lot of CPU, but when it gets the next block from disk it must wait. But, if you pipe a copy into the uncompress, the copy will do all the waiting and the uncompress will run full speed IF the pipe buffers data. An even better example is going the other way... compressing a file TO disk. So in general, if the source can jam data out faster then the destination can read it, you want buffered pipes so the destination can run full speed. -Matt
peter@sugar.UUCP (Peter da Silva) (09/05/87)
> So in general, if the source can jam data out faster then the > destination can read it, you want buffered pipes so the destination can run > full speed. I quite agree. However, there's another use for pipes. While they can save a hell of a lot of one scarce resource (wallclock time), they do it at the expense of another one (memory). My suggestion was a way to use pipes to save a resource that is (for me, anyway) even more scarce. -- -- 512K Amiga... it's not dead yet. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- U <--- not a copyrighted cartoon :->
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/09/87)
>> So in general, if the source can jam data out faster then the >> destination can read it, you want buffered pipes so the destination can run >> full speed. > >I quite agree. However, there's another use for pipes. While they can save a >hell of a lot of one scarce resource (wallclock time), they do it at the >expense of another one (memory). My suggestion was a way to use pipes >to save a resource that is (for me, anyway) even more scarce. If STDIO uses 1K buffering, a 4K static PIPE: would be plenty big enough. 4K isn't that much. -Matt
peter@sugar.UUCP (Peter da Silva) (09/12/87)
4K here, 4K there... pretty soon you're talking about real memory... -- Not Senator Dirksen. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- 'U` <-- Public domain wolf.