From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3e1162e60612061607j545aa76qa2415fc35ae5f912@mail.gmail.com>
Date: Wed,  6 Dec 2006 16:07:05 -0800
From: "David Leimbach" <leimy2k@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: Re: [9fans] OT: cannonical set of queue ops
In-Reply-To: <676c3c4f0612061458gd767117qb67b4bce8b027e43@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <15215407ef3dbfddfed3946505e2dc78@quintile.net>
	<676c3c4f0612060835x414a779ao6e1f5fcbe021aba9@mail.gmail.com>
	<283f5df10612061436i5179e5f7mc7930ebf1f3ec280@mail.gmail.com>
	<676c3c4f0612061458gd767117qb67b4bce8b027e43@mail.gmail.com>
Topicbox-Message-UUID: ebefee6a-ead1-11e9-9d60-3106f5b1d025

> I agree with you that it's usually better to block than to busy-wait.
>

Oh how I wish most of the world understood the benefits of overlapping
I/O and computations.  Low latency appears to be a win when polling,
but being able to do more than one thing (even in a pseudo-sense) at a
time is often a huge win a lot of times.

Doing I/O as fast as possible for the sake of doing I/O as fast as
possible is sometimes not so important if you can schedule work tasks
to overlap the I/O.  Then I/O overheads can even sometimes be almost
completely masked out.

But we just gotta win those microbenchmarks!!