Linux-kernel mailing list archive 1998-31,: Re: kernel compile time comparison (2.0 vs 2.1 with 64MB)

# Re: kernel compile time comparison (2.0 vs 2.1 with 64MB)

MOLNAR Ingo (mingo@chiara.csoma.elte.hu)
Mon, 3 Aug 1998 18:47:11 +0200 (CEST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Ulrich Drepper: "Re: execve("libm.so") -> SIGSEGV instead of ENOEXEC."
- Previous message: Camm Maguire: "2.0.34 error: Freelist block not free"

On Mon, 3 Aug 1998, Andrew Derrick Balsa wrote:

> > > Conclusion: if you want faster compilations, get a faster CPU. Going
> > > from Linux 2.0.x to 2.1.x will get you a negligible performance gain for
> > > this kind of task.
> >
> > this is not necessarily true for all systems. Although the system in
> > question was a UP box, it's i think worth to mention that compilation
> > speeds on SMP improve measurably with 2.1.
>
> Because of finer-grained kernel locking, yes. [...]

simply because we schedule better.

> > also, compilation _can_ be 'kernel-bound' on UP too, just try compiling
> > Linux on a say 4MB box. (or 8MB)
>
> Bad example: then you are not kernel bound, but memory (swap) bound. And
> 2.0.x is noticeably *faster* than 2.1.x in low memory machines.

hm, and where is the swapping logic? in the kernel ...

we do not depend on the speed of the kernel, we depend on the decisions
made by the kernel. (or rather, kernel developers ;)

so to get back to the point:

> > > Conclusion: if you want faster compilations, get a faster CPU.

get a faster CPU, get enough memory and get a kernel that does the right
decisions. Because even for 'CPU bound' things like compilation we can
make bad decisions, especially on more complex hardware. (SMP, page
coloring, etc., etc.)

-- mingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

- Next message: Ulrich Drepper: "Re: execve("libm.so") -> SIGSEGV instead of ENOEXEC."
- Previous message: Camm Maguire: "2.0.34 error: Freelist block not free"