P4 compile options

P4 compile options

[Margit Schubert-While]

Maybe a dumb question -
Is it possible to use the "-march=pentium4 -mfpmath=sse -msse2" options
for a P4 ?
I notice anything over a P2 just gets "-march=i686".

Margit

Re: P4 compile options

[Dave Jones]

On Thu, Nov 21, 2002 at 09:18:30PM +0100, Margit Schubert-While wrote:
 > Maybe a dumb question -
 > Is it possible to use the "-march=pentium4 -mfpmath=sse -msse2" options
 > for a P4 ?
 > I notice anything over a P2 just gets "-march=i686".

This is already done in 2.5. (Well, the -march anyways)

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: P4 compile options

[Denis Vlasenko]

On 21 November 2002 18:40, Dave Jones wrote:
> On Thu, Nov 21, 2002 at 09:18:30PM +0100, Margit Schubert-While wrote:
>  > Maybe a dumb question -
>  > Is it possible to use the "-march=pentium4 -mfpmath=sse -msse2"
>  > options for a P4 ?
>  > I notice anything over a P2 just gets "-march=i686".
>
> This is already done in 2.5. (Well, the -march anyways)

I'd say benefits of compiling p4-optimized code are questionable.
Are you sure your kernel will run faster, not slower?
Benchmark numbers? Or it's only warm and fuzzy feeling?

Warm and fuzzy feelings of kernels compiled for very new processors
quickly disappear when you try to boot e.g. 486 with them ;)
--
vda

Re: P4 compile options

[Dave Jones]

On Fri, Nov 22, 2002 at 11:22:53AM -0200, Denis Vlasenko wrote:
 > > This is already done in 2.5. (Well, the -march anyways)
 > I'd say benefits of compiling p4-optimized code are questionable.

On what grounds ?

 > Are you sure your kernel will run faster, not slower?
 > Benchmark numbers? Or it's only warm and fuzzy feeling?

The kernel mailing list archives are that way --->

 > Warm and fuzzy feelings of kernels compiled for very new processors
 > quickly disappear when you try to boot e.g. 486 with them ;)

"Doctor, it hurts when I do this"

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: P4 compile options

[Denis Vlasenko]

On 22 November 2002 07:26, Dave Jones wrote:
> On Fri, Nov 22, 2002 at 11:22:53AM -0200, Denis Vlasenko wrote:
>  > > This is already done in 2.5. (Well, the -march anyways)
>  >
>  > I'd say benefits of compiling p4-optimized code are questionable.
>
> On what grounds ?

I consider 16-byte code alignment as way too big.
P4 zealots can demand even more I guess :(
I will happily change my mind when/if I'll see
favorable speed/kernel size benchmarks. Until then,
I think 4-byte alignment is closest to sanity.

Not exactly P4 related but: if you tell gcc your
processor has cmov, gcc will try to use it.
Results: 
* gcc code is worse with cmov than without
* some CPUs (Cyrix?) have slow cmovs (microcoded?)
* you lose whenever you try to use your code
  on cmov-less CPU.

Dave, I am absolutely sure _you_ do not compile
for P4 needlessly, but lots of ordinary people
do that just to be hip. I wanted to point out
why it may be undesirable.

>  > Are you sure your kernel will run faster, not slower?
>  > Benchmark numbers? Or it's only warm and fuzzy feeling?
>
> The kernel mailing list archives are that way --->
>
>  > Warm and fuzzy feelings of kernels compiled for very new
>  > processors quickly disappear when you try to boot e.g. 486 with
>  > them ;)
>
> "Doctor, it hurts when I do this"

It hurts even more when you need to recompile
gcc,glibc,X,KDE,mozilla,etc etc etc :)
I payed no attention when I compiled stuff on my home Duron...

>From the moment when I tried to revive oldie 486
I started to ./configure everything for 386 ;)
--
vda

Re: P4 compile options

[Dave Jones]

On Fri, Nov 22, 2002 at 01:04:39PM -0200, Denis Vlasenko wrote:

 > I consider 16-byte code alignment as way too big.
 > P4 zealots can demand even more I guess :(
 > I will happily change my mind when/if I'll see
 > favorable speed/kernel size benchmarks. Until then,

I think there's a misunderstanding here.
The march=pentium4 option is only used when you select
"build me a pentium 4 kernel" You do realise that right?
Generic kernels don't change 1 bit.

 > I think 4-byte alignment is closest to sanity.

You know where to find the Intel P4 optimisation manuals..

 > Not exactly P4 related but: if you tell gcc your
 > processor has cmov, gcc will try to use it.

So what ? Show me a P4 without cmov.

 > Results: 
 > * gcc code is worse with cmov than without
 > * some CPUs (Cyrix?) have slow cmovs (microcoded?)
 > * you lose whenever you try to use your code
 >   on cmov-less CPU.

  <------------ The point.
                              --------------> You.

Cmov is completely irrelevant here.
Sure its still an optional instruction which
should be tested for before use, but until Intel
make a P4 without CMOV, adding march=pentium4
is harmless.
 
 > Dave, I am absolutely sure _you_ do not compile
 > for P4 needlessly, but lots of ordinary people
 > do that just to be hip.

Those are probably the same folks who run Gentoo/Slackware/ or
some-other-compile-everything-myself-because-I've-too-much-time-on-my-hands-distro.
Fine, let them be happy.
If some loon wants a P4 optimised /bin/ls, that's his problem,
but optimisation of key components (like say, the kernel) _is_
important.

 > I wanted to point out why it may be undesirable.

All you've pointed out is that a P4 kernel won't run
optimally on a 486. Well surprise, it won't run at all.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: P4 compile options

[Denis Vlasenko]

On 22 November 2002 08:54, Dave Jones wrote:
> On Fri, Nov 22, 2002 at 01:04:39PM -0200, Denis Vlasenko wrote:
>  > I consider 16-byte code alignment as way too big.
>  > P4 zealots can demand even more I guess :(
>  > I will happily change my mind when/if I'll see
>  > favorable speed/kernel size benchmarks. Until then,
>
> I think there's a misunderstanding here.
> The march=pentium4 option is only used when you select
> "build me a pentium 4 kernel" You do realise that right?
> Generic kernels don't change 1 bit.
>
>  > I think 4-byte alignment is closest to sanity.
>
> You know where to find the Intel P4 optimisation manuals..
>
>  > Not exactly P4 related but: if you tell gcc your
>  > processor has cmov, gcc will try to use it.
>
> So what ? Show me a P4 without cmov.
>
>  > Results:
>  > * gcc code is worse with cmov than without
>  > * some CPUs (Cyrix?) have slow cmovs (microcoded?)
>  > * you lose whenever you try to use your code
>  >   on cmov-less CPU.
>
>   <------------ The point.
>                               --------------> You.


I find it's far too easy for me to talk on lkml than
to do something useful... I'll try to *not* reply next time :)

Let's start from the start.
This is an original message which started this thread:

On 21 November 2002 18:18, Margit Schubert-While wrote:
> Maybe a dumb question -
> Is it possible to use the "-march=pentium4 -mfpmath=sse -msse2"
> options for a P4 ?
> I notice anything over a P2 just gets "-march=i686".

It sounds like: "I've got a P4, I want my kernel use each and every P4ism
possible. I want. I want. I want.  How to do it?" (a bit exagerrated :)

An important question is missing here: is a particular P4ism useful?
It is ok to use P4isms *if* one is sure they lead to better kernel.

What -mfpmath=sse or -msse2 will give us? Probably nothing since kernel
do not use fp (well, almost). And if it would use 'em, use of sse2 can
*slow down* context switch. I'm not sure, but _it needs testing_ before
we "optimize" kernel with such options.

Margit Schubert-While <margitsw@t-online.de> has an excellent opportunity
to compile a handful of kernels, run, say, contest with them and report
his findings. ;)
--
vda

P4 compile options

[Margit Schubert-While]

Quite so, Dave.
I just wondered what that might do with 2.4.xx.
Following is based on 2.4.xx.
In the next few days, I'll be setting up an Informix application on my P4 box.
This is a read-only app.
Bumping "shmmax" and configuring Informix ensures that all the data is
held in shared memory (after the initial read).
Thereafter, this is a tight semaphore/shared memory (also 
user-program/Informix)
reaction with the kernel.
(This really gets the processor fan(s) going!)
This app takes ca. 80 mins on a dual P3 (1 GHz) and (Hmm) 90 mins on a 
single P3 (1 GHz)
(Before anybody comments, all boxes (mine as well) have Adaptec 
U160/controller/disks)
So, Let's just wait and see !

Margit