On Wed, Feb 14, 2001 at 12:11:12PM +0530, Shridhar Daithankar wrote:
> Upendra wrote:
> 
> > The HP RISC cpu could be actually faster than PIII, as the clock cycles
> > are much lower for RISC chips. (see also clock cycles for sparc).
> >
> 
> I doubt. The facts posted by Raju for SGI machines seem more relevant.
> 
> 

Its simple, because of the reduced instruction set, RISC cpus take less clock cycles. 
I dont have exact numbers, its a well known fact that Sparc CPUs deliver higher 
performance than Intel chips at nearly half clock speed.
Even in the Intel world clock speeds are deceptive, see the P-4 fiasco. Knowing how
gullible the public are, chip makers are focussing more on increasing clock speeds
than give real world performance.

Ok, so you agreed that HP hardware is orders of magnitude better than a PC.
That is why we keep hearing "when will linux be enterprise ready?", which means
getting linux run better on bigger machines.


> Well, to quote,  'Kernel compilation comes first in linux benchmarking' and I was
> just identifying responsiveness of system under heavy loads. That's sure an
> important parameter of benchmarking though not full benchmarking.
> 

Compilation is just a CPU intensive job. Having faster hard disk doesnt really improve
the time taken for compilation.
So why is kernel compilation used for benchmarking? see
http://www.linuxgazette.com/issue23/bench2.html#ss4

And the responsiveness depends on what design decisions the linus makes in that year :)
Scheduling in linux is designed to utilise the low-end hardware better and cannot 
afford
 to waste cpu time to give superflous responsiveness on the shell prompt.
Think about this: Would  you like to 'nice' the make process to get better 
responsiveness
and let compilation take double the time OR let the default be as it is.

I like the default of slow response.

-Upendra

----------------------------------------------
An alpha version of a web based tool to manage
your subscription with this mailing list is at
http://lists.linux-india.org/cgi-bin/mj_wwwusr

Reply via email to