🚀 go-pugleaf

In article <2121@coyote.UUCP>, shoens@rufus.almaden.ibm.com writes:
|> Jason Solinsky  ...
|> 
|> > In how many of these examples are we actually concerned with processor
|> > performance?  In editors and word processors we certainly aren't ...
|> > In the case of a database, I would not expect it to be processor limited.
|> 
|> As you have more cycles to fool with you get to put more function in,
|> of course.  So where I previously edited nroff source with ed, I now
|> use a system like Framemaker with X-windows.  Database systems are
|> typically CPU bound because disks have been slow forever, so the problem
|> of disk parallelism has already been tackled.  Besides, if you analyze
|> the popular transaction benchmarks you can see that the disk bandwidth
|> required is relatively small, assuming reasonably-sized buffer pools.
|> For complex queries, there's even more processing to do and more opportunity
|> for smart data placement on disk and sequential prefetch.

Several people wrote me concerning the fact that their word processors and
editors do this, that, and the other thing. HOWEVER, in all of those cases and
apparently in the two examples mentioned above, there exists a huge (or at the
very least presently underutilized) degree of parallelism. When you have an
idle CPU there will always be additional things that software people would
like to run on it, but the practical examples are OVERWHELMINGLY
under-parallelized in their present day incarnations.

This is certainly true of a CPU running an editor while updating several macros
within the editor and then running several tasks in the background. It is again
true of most database programs which will typically be very parallelizable
at the higher levels of examination.

What I am trying to say is that when a task which has been non-cpu bound, is
modified such that it becomes cpu-bound, the modifications invloved are
typically excellent candidates for parallelization. Thus it still holds that
"general purpose" computing can support the degree of parallelization available
to a deep pipelined "hyperscalar" uP.

Jason W. Solinsky