Upendra wrote:
> On Wed, Feb 14, 2001 at 12:11:12PM +0530, Shridhar Daithankar wrote:
> > 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.
OK.
>
> I dont have exact numbers, its a well known fact that Sparc CPUs deliver higher
> performance than Intel chips at nearly half clock speed.
Well thats performance of system and not the CPU. Internal bus architectute can make
lot of
difference as pointed out by Raju.
> 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.
Well, for intel CPUs, I know that from the ages of 200 MHz speed, intel is shipping
CPUs that
double the clock internally. Again I don't know the internal of HP machines.
As far as P4 fiasco is concerned, there are two reasons.
1.P4 is actually lame. That's partially true in light of what AMD is shipping with
athlon and
would be sledge hammer. But still it's not very unreasonable CPU.
2.The biggest drawback is there is no software that's specially optimised for P4. I
bet HP
(RISC in general) can tweak out a lot of performance due to tighter intergration
between
hardware and CPU. If RISC vendor started supporting third party hardware like PCs
especially
third party mobos, I am not sure how long they can keep the magnitudes of performance
advantage. Some advantage will be there but not as much as it exists today.
> Ok, so you agreed that HP hardware is orders of magnitude better than a PC.
Well. That's true beyond doubt.
> That is why we keep hearing "when will linux be enterprise ready?", which means
> getting linux run better on bigger machines.
That's two fold statement.
1)Getting linux run on 'big' machines.
2)Getting linux run better on 'big' machines.
I haven't seen linux on RISC. Can anybody compare linux/Solaris on sparc and linux v/s
True64Unix/NT(Sorry for joking), on alpha. I am sure linux will churn out advantage in
at
least some area, if not over all better.
> Compilation is just a CPU intensive job. Having faster hard disk doesnt really
>improve
> the time taken for compilation.
Along with CPU, that hogs the system BUS too. Now that leaves only I/O bus(if it's
separate.)
> So why is kernel compilation used for benchmarking? see
> http://www.linuxgazette.com/issue23/bench2.html#ss4
>
Very good. I knew it would appear somewhere along. That's a very good document. Thanks
for
the link. I had lost it in due period of time.
> 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.
Responsiveness in shell prompt was again an example. Imagine this, I need to run a
database
along with compilation as in our case. Now what? Shell demands much less resources for
responsiveness than a database because you (generally) don't hammer it electronically
as in
case of databases.
Responsiveness is rather related to running more than one tasks, each hogging CPU and
still
perform fair.
I admit I haven't stressed linux that much. Only stress test I did was running KMP3
along
kernel compilation. It too about 9 minutes for 'make bzImage' rather than usual 7:22
minutes
on my K6-II 500. That's anyway slow w.r.t. above link. But it's for kernel 2.2.16-3.
> 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.
That depends on the situation.
> I like the default of slow response.
Your choice. Must have been very right for you. But I agree defaults are good enough.
> -Upendra
>
Shridhar
----------------------------------------------
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
