Robert M. Hyatt wrote:
>
> Now that 2.2 has hit the ground, I have one topic to suggest for 2.3
> development. Probably more appropriate in the normal kernel mailing
> list, but it is a performance issue, and since my machines are SMP-based,
> maybe it is appropriate here as well.
>
> The topic is memory-to-cache mapping.. and the current more-or-less
> random page allocation approach is fine for most programs, but for those
> that are _very_ cpu intensive, it leaves a lot to be desired. Since all
> of the cache systems we are going to see for the forseeable future are
> going to have some sort of 'direct mapping' at their core (ie 4-way
> set associative still direct maps to the set) there is going to be a
> good way to lay out a program in memory (several good ways in fact)
> but there are far more bad ways. And statistics says we get the bad ways
> far more often than we get the good ways. :)
>
> The issue for me is program optimization. I make a change that obviously
> results in better instruction scheduling and the program runs slower
> because now I get less cache performance due to the way the program was
> loaded _this_ time.
I'm very interested in making codes faster (number-crunching is what we
do here).
But: I get much more than 2% variations on codes, (try 20%+). It
depends on the nature of the code, and my feeling is that it's due to
alignment problems.
I find that running a code under X instead of in a VT can make a huge
difference for good or for bad (like tens of percent). This is
surprising to me.
I'm no expert, but I've seen various comments over the last year or two
which support this view (alignment issues). For some reason, Linux (or
is it the compiler's fault?) doesn't always ensure decent alignment of
the critical bits, and this may be worsened when variables are on the
stack. (When you're using someone else's code which puts lots of things
on the stack you don't have a lot of options.)
(Perhaps in fact this issue is the same as Robert's cache mapping issue
but the magnitude of the effect I see is much large than he
describes...)
Is anyone else up to speed on alignment issues?
Neil
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
