Re: On linux kernel packaging issue
#include <hallo.h>
* Cameron Patrick [Sun, Nov 09 2003, 11:52:41PM]:
> On Sun, Nov 09, 2003 at 03:37:11PM +0100, Eduard Bloch wrote:
> | #include <hallo.h>
> | * Michael Poole [Sun, Nov 09 2003, 09:22:13AM]:
> | > Eduard Bloch writes:
> | >
> | > > Do you see now that 8 of your 10 percent come directly from the
> | > > application code and other two maybe from the optimized libc? There is
> | > > not{hing| much} we have won using an optimised kernel. But the placebo
> | > > effect has been demonstraded once again.
> | >
> | > You have not shown what you claim you have shown. You have shown that
> |
> | No. Please read my initial mail then and what Glenn tried to proove with
> | his bzip2 test.
>
> I believe that Michael is correct. A summary of the messages leading up
> to this one on the thread is as follows: [with my comments in square
> brackets]
That is not a summary of the thread, that is a summary of YOUR
interpretation of the thread.
> Nikita: There are significant performance gains optimising the
> kernel for a modern CPU rather than i386.
>
> Eduard: Optimising kernel code doesn't help as other hardware is the
> limiting factor.
No. The hardware limits were just an example to show where the
optimisation do not make any sence, as well as in other parts of the
kernel.
> Nikita: No, you're wrong.
>
> Andrew Suffield: Prove that optimising for a particular CPU makes things
> faster rather than slower.
No. Read and think about it:
|> Cpu-specific task management, IRQ processing, cache alignment, etc is
|> being used on higher processors.
|
|Please provide carefully documented evidence of the performance gains
|that you are claiming, not handwaving. Evidence of a difference is not
|the same thing; anybody who has any experience with low-level
> Eduard: Glenn's comparison [of user-space code] is invalid as his
> kernel is optimised in both cases. Provides an example of bzip2 running
> on a P4 kernel vs a "vanilla" kernel, with no significant performance
> difference. Therefore optimising the kernel yields no performance
> advantage.
Which was the thing questioned above...
> Glenn: I was comparing user-space optimisation so the kernel is
> irrelevant.
> [i.e. Glenn's point was about optimisation in general, rather than
He did not make his point clear. And answered to a mail discussing
KERNEL ISSUES. If you like to talk about general benefits of code
optimisation, start a new thread.
> Eduard: Yeah, user-space optimisation is the only thing that matters,
> here's another "benchmark" [more or less the same as Glenn's]. See,
> I was right!
> [Eduard's comparison here provides another data point in favour of
> optimisation making a difference in bzip2. Once again utterly
> irrelevant for benchmarking different kernels. If one wanted to compare
> the effects of optimising the kernel, a valid benchmark would be one
> which actually spends most of its time executing kernel code rather than
> user code.]
>
> Michael and Cameron: No-one has shown anything remotely interesting
> here about the effects of optimisating kernel code. Eduard's
> interpretation of his own benchmark is invalid.
I did not try to test the kernel. I demonstrated the same things you
meant. Show me the "invalid interpretation" or just stop rephrasing
things in the way you like them.
> Eduard: No it's not!
Nice reduction to the thing you wish to see. Please cool down and reread
the discussion without emotions, then notice:
|> > not{hing| much} we have won using an optimised kernel. But the placebo
|> > effect has been demonstraded once again.
|>
|> You have not shown what you claim you have shown. You have shown that
|
|No. Please read my initial mail then and what Glenn tried to proove with
|his bzip2 test.
and realize that you already tried to force an opinion that I did not
have.
MfG,
Eduard.
--
Ein Mann liebt Keusche und ist es selbst nicht; bei Weibern ist's
umgekehrt.
-- Jean Paul
Reply to: