On Sat, 7 Nov 1998, Stephen Costaras wrote:
> I don't see how this would really help with general I/O performance,
> the RAID code is in the kernel, plus with the RAID thread itself
> taking less than 20% of the CPU (usually around 10%) I don't see this
> as a processor issue but more of a hardware (motherboard, memory bandwidth,
> disk bandwidth) issue.
It isn't a processor issue -- it's a driver optimization issue.
The pgcc is not only a cpu-optimizer, it's a more aggressive logical
software optimizer than is found in good old GCC 2.7.2.x. EGCS builds on
GCC's already stable -O6, with more software optimization, and pgcc builds
on egcs with a little more software optimization and a lot more hardware
optimization.
Maybe it also has to do with the fact that Intel pee-sea's are so
completely cpu-centric, relying (and WAITING) on it to do virtually
EVERYTHING.
There are certain aspects of filesystem performance that can be
described in software. And trading off higher memory consumption for
higher execution speed, is always cool if you can afford the memory. It
does things like unrolling loops. i.e., (a=1+1, a=1+2, a=1+3) rather than
(a=1+(n=1 to 3)).
I dont know what it'll do to RAID, but it'll affect the filesystem
that's running on the RAID.
Nonetheless, in some cases, the benchmarks will rise. That's my
main reason for linking software optimization to the issue.
I dont write compilers or drivers, so if my explanation is fulla
crap, then someone please explain why my benchmarks rise with pgcc :) If
I'm confusing you, then just go ahead and give it a shot and benchmark it!
