Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Dennis Castleman <DennisCastleman@oaktech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: your mail
Date: Fri, 18 Apr 2003 02:03:45 +0200	[thread overview]
Message-ID: <20030418020345.A6962@linux-mips.org> (raw)
In-Reply-To: <56BEF0DBC8B9D611BFDB00508B5E2634102F10@TLEXMAIL>; from DennisCastleman@oaktech.com on Thu, Apr 17, 2003 at 10:53:57AM -0700

On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:

> Anybody know the performance differences I can expect using a MIPS 5K core
> @250 Mhz in 64bit mode versus 32bit mode?

As a rule of thumb - less performance.  64-bit code is typically larger
resulting in lower cache hit rate.  And since performance optimization
these days is essentially equivalent to maximising the cache hit rate
going 64-bit usually means a performance drop due to the drastically
larger size of code and data.

On the positive side for 64-bit stuff there's the possibility to do
64-bit computations with just one instruction, move data with less
instructions, use twice as many double precission fp registers that are
offered by 64-bit ABIs and more calling sequences.

The first two paragraphs were sort of a generic statement regarding
32-bit vs. 64-bit software on MIPS processors and affect both kernel and
userspace.  There's a few additional issues with the Linux kernel.
The 32-bit kernels requires all memory to be addressable through KSEG0
which limits it to at most 512MB; typically the limit is more like 256MB.
Memory above 512MB physical address can only be used as highmem.  That's
fairly inefficient and requires alot of special care when writing new
kernel software.  For processors that suffer from virtual aliases in
their data cache highmem currently is frighteningly inefficient - and
high memory pressure on lowmem doesn't help either.  So from a certain
point on that's simply making a 64-bit kernel is simply the better
idea - even for running 32-bit software.  That in particular applies
to very I/O intensive stuff.

In short - the right choice is a tradeoff between the hardware platform
and the application's requirements.  Choose wrong and you'll curse
loudly :-)

  Ralf

  parent reply	other threads:[~2003-04-18  0:04 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-17 17:53 Dennis Castleman
2003-04-17 18:17 ` your mail Jun Sun
2003-04-17 20:15   ` Greg Lindahl
2003-04-18  0:03 ` Ralf Baechle [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-05-06  5:52 Jiaxun Yang
2020-05-07 11:00 ` your mail Thomas Bogendoerfer
2018-08-27 14:50 Christoph Hellwig
2018-08-31 20:23 ` your mail Paul Burton
2018-03-09 15:12 [PATCH 00/14] Enable SD/MMC on JZ4780 SoCs Ezequiel Garcia
2018-03-09 15:12 ` [PATCH 08/14] mmc: jz4740: Add support for the JZ4780 Ezequiel Garcia
2018-03-09 17:51   ` [PATCH 08/14] mmc: jz4740: Add support for the JZ4780, Paul Cercueil
2018-03-09 22:31     ` your mail James Hogan
2018-03-09 22:31       ` James Hogan
2008-01-22  0:00 (no subject) Thiemo Seufer
2008-01-28 17:51 ` your mail Ralf Baechle
2005-04-28 19:15 Bryan Althouse
2005-04-29 11:02 ` your mail Ralf Baechle
2003-04-18  0:08 Dennis Castleman
2003-03-29  6:54 Avinash S.
2003-03-29  7:25 ` your mail Thiemo Seufer
2002-10-26 19:48 Zajerko-McKee, Nick
2002-10-26 20:08 ` your mail Daniel Jacobowitz
2002-10-26 20:32 ` Greg Lindahl
2001-10-03 14:28 Marian Kafadarov
2001-10-03 15:52 ` your mail Martin Schulze
     [not found] <5.0.0.25.0.20010404172906.00a4bce8@vmspop.isc.rit.edu>
2001-04-04 21:37 ` Matthew Fredrickson
2001-04-05  5:08   ` Ralf Baechle
2001-02-15  0:27 Deepa  Suresh
2001-02-15 11:03 ` your mail Geert Uytterhoeven
2001-01-04  1:36 John Van Horne
2001-01-04 15:36 ` your mail Ralf Baechle
2001-01-04 16:22   ` Maciej W. Rozycki
2001-01-04 16:40     ` Joe deBlaquiere
2001-01-04 17:13       ` Ralf Baechle
2001-01-04 17:46         ` Joe deBlaquiere
2001-01-04 18:12           ` Maciej W. Rozycki
2001-01-04 17:18       ` Maciej W. Rozycki
1997-08-09 17:16 Vincent Renardias
1997-08-09 17:41 ` your mail Ralf Baechle
1997-08-09 17:41   ` Ralf Baechle
1997-08-09 19:40   ` Vincent Renardias
1997-08-09 19:42     ` Ralf Baechle
1997-08-09 19:42       ` Ralf Baechle
1997-08-09 21:05       ` Vincent Renardias
1997-08-09 21:11         ` Ralf Baechle
1997-08-09 21:11           ` Ralf Baechle
1997-08-10  2:57           ` Vincent Renardias
1997-08-09 22:53         ` Mike Shaver
1997-08-09 22:53           ` Mike Shaver

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=20030418020345.A6962@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=DennisCastleman@oaktech.com \
    --cc=linux-mips@linux-mips.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox