Re: On linux kernel packaging issue
On Sun, Nov 09, 2003 at 05:14:44PM +0100, Eduard Bloch wrote:
| That is not a summary of the thread, that is a summary of YOUR
| interpretation of the thread.
I won't dispute this. :-)
| > 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.
Hmm. Okay.
| > 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
Sounds about right to me. I claim that "provide carefully documented
evidence of performance gains" can be sensibly paraphrased in this
context as "prove that optimising for a particular CPU makes things
faster".
| > 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...
No. You were inferring from "bzip2 doesn't run any faster on an
optimised kernel" (a premise which I won't dispute) that optimising the
kernel has no performance gains (which is not necessarily the case).
| > 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.
I'll grant you that. It's still the only sane way that I can find to
parse what he wrote, though.
| And answered to a mail discussing KERNEL ISSUES. If you like to talk
| about general benefits of code optimisation, start a new thread.
Fair enough.
| > 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.
Then what were you trying to do when you timed the same executable
running on two differently-optimised kernels?
| I demonstrated the same things you meant. Show me the "invalid
| interpretation" or just stop rephrasing things in the way you like
| them.
You seemed to interpret a benchmark showing that bzip2 doesn't spend
much of its time in kernel space when you ran it as showing "there is
not much we have won using an optimised kernel". Well, surprise
surprise, if you run a program that doesn't spend much time in kernel
code, optimising that kernel code won't get you much.
What would be more interesting to see is what kind of effects an
optimised kernel has on code that /does/ spend a long time in kernel
space, and how common those kind of applications are. (Although I
suspect the latter would depend a lot on what you used the machine for -
which shouldn't really be a surprise.)
| 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.
Well, Glenn didn't really put many words around his output from timing
bzip2, so any claims about what he was trying to prove are speculative.
I think it is apparent from his previous email in the thread that he was
trying to demonstrate that compiler optimisations make a difference,
though. Admittedly, timing two bzip2 binaries is not the most
meaningful benchmark ever, and it certainly isn't the kind of evidence
that Andrew Suffield was after. Your rebuttal did seem to me to be
missing the point, however weak that point may have been.
Cameron.
Reply to: