All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cort Dougan <cort@fsmlabs.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Why Plan 9 C compilers don't have asm("")
Date: Fri, 6 Jul 2001 02:38:35 -0600	[thread overview]
Message-ID: <20010706023835.A5224@ftsoj.fsmlabs.com> (raw)
In-Reply-To: <200107040337.XAA00376@smarty.smart.net> <20010703233605.A1244@zalem.puupuu.org> <20010704002436.C1294@ftsoj.fsmlabs.com> <9hvjd4$1ok$1@penguin.transmeta.com>
In-Reply-To: <9hvjd4$1ok$1@penguin.transmeta.com>; from torvalds@transmeta.com on Wed, Jul 04, 2001 at 05:22:44PM +0000

I'm talking about _modern_ processors, not processors that dominate the
modern age.  This isn't x86.  I don't believe that even aggressive
re-ordering will cause a serious hit in performance on function calls.
Unconditional branches are definitely predictable so icache pre-fetches are
not more complicated that straight-line code.

Measurement is more important, though.  I've rejected a number of
optimizations from people (including many of my own) that were "obvious
enhancements" because of what they showed in real-world measurements.  If
it doesn't run faster, despite the theory being "right", it's worthless.

  reply	other threads:[~2001-07-06  8:38 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-04  3:37 Why Plan 9 C compilers don't have asm("") Rick Hohensee
2001-07-04  3:36 ` Olivier Galibert
2001-07-04  6:24   ` Cort Dougan
2001-07-04  8:03     ` H. Peter Anvin
2001-07-04 17:22     ` Linus Torvalds
2001-07-06  8:38       ` Cort Dougan [this message]
2001-07-06 11:43         ` David S. Miller
2001-07-06 18:44         ` Linus Torvalds
2001-07-06 20:02           ` Cort Dougan
2001-07-08 21:55           ` Victor Yodaiken
2001-07-08 22:28             ` Alan Cox
2001-07-08 22:29             ` David S. Miller
2001-07-09  1:22             ` Johan Kullstam
2001-07-21 22:10       ` Richard Henderson
2001-07-22  3:43         ` Linus Torvalds
2001-07-22  3:59           ` Mike Castle
2001-07-22  6:49           ` Richard Henderson
2001-07-22  7:44             ` Linus Torvalds
2001-07-22 15:53               ` Richard Henderson
2001-07-22 19:08                 ` Linus Torvalds
2001-07-04  7:15 ` pazke
2001-07-04 17:32 ` Don't feed the trooll [offtopic] " Ben LaHaise
2001-07-05  1:02 ` Michael Meissner
2001-07-05  1:54   ` Rick Hohensee
2001-07-05 16:54     ` Michael Meissner
  -- strict thread matches above, loose matches on Subject: below --
2001-07-04 10:10 Rick Hohensee
2001-07-05  3:26 Rick Hohensee
2001-07-06 17:24 Rick Hohensee
2001-07-06 23:54 ` David S. Miller
2001-07-07  0:16   ` H. Peter Anvin
2001-07-07  0:37     ` David S. Miller
2001-07-07  6:16 Rick Hohensee
     [not found] <mailman.994629840.17424.linux-kernel2news@redhat.com>
2001-07-09  0:08 ` Pete Zaitcev
2001-07-09  0:28   ` Victor Yodaiken
2001-07-09  3:03 Rick Hohensee
2001-07-23  4:39 Rick Hohensee

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=20010706023835.A5224@ftsoj.fsmlabs.com \
    --to=cort@fsmlabs.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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.