All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@codemonkey.org.uk>
To: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: Margit Schubert-While <margitsw@t-online.de>,
	linux-kernel@vger.kernel.org
Subject: Re: P4 compile options
Date: Fri, 22 Nov 2002 10:54:38 +0000	[thread overview]
Message-ID: <20021122105438.GA16662@suse.de> (raw)
In-Reply-To: <200211221013.gAMADpp31088@Port.imtp.ilyichevsk.odessa.ua>

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

  reply	other threads:[~2002-11-22 10:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-21 20:18 P4 compile options Margit Schubert-While
2002-11-21 20:40 ` Dave Jones
2002-11-22 13:22   ` Denis Vlasenko
2002-11-22  9:26     ` Dave Jones
2002-11-22 15:04       ` Denis Vlasenko
2002-11-22 10:54         ` Dave Jones [this message]
2002-11-24 16:52           ` Denis Vlasenko
  -- strict thread matches above, loose matches on Subject: below --
2002-11-22 12:12 Margit Schubert-While

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021122105438.GA16662@suse.de \
    --to=davej@codemonkey.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=margitsw@t-online.de \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.