From: Jeffrey Hundstad <jeffrey.hundstad@mnsu.edu>
To: David Lang <dlang@digitalinsight.com>
Cc: Jesper Juhl <jesper.juhl@gmail.com>, Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: 64-bit vs 32-bit userspace/kernel benchmark? Was: Athlon 64 X2 cpuinfooddities
Date: Tue, 10 Jan 2006 14:50:05 -0600 [thread overview]
Message-ID: <43C41DFD.9000507@mnsu.edu> (raw)
In-Reply-To: <Pine.LNX.4.62.0601101232420.5425@qynat.qvtvafvgr.pbz>
David Lang wrote:
> On Tue, 10 Jan 2006, Jeffrey Hundstad wrote:
>
>>
>>> On 1/10/06, Andi Kleen <ak@suse.de> wrote:
>>>
>>>> On Tuesday 10 January 2006 03:12, Jesper Juhl wrote:
>>>>
>> ...
>>
>>>> Ah - how legacy.
>>>>
>>>>
>>> Yeah, but since my distro of choice is 32bit only and I don't much
>>> feel like porting it myself or using an unofficial port (slamd64) I'm
>>> sticking with a 32bit userspace. And as long as userspace is pure
>>> 32bit there doesn't seem to be much point in building a 64bit kernel.
>>> And I only have 2GB of RAM, so I don't have a use for the larger 64bit
>>> address space.
>>> I also don't run any apps that do a lot of math on >32bit numbers, so
>>> there's not much gain there either.
>>> I guess I would bennefit from the extra GPR's, but then I would at the
>>> same time loose a bit by all pointers being 64bit - both lose some
>>> disk space due to larger binaries and I'd have increased memory use
>>> and less efficient L1/L2 cache use.
>>>
>>> I don't think there would actually be much gain for me in switching to
>>> a 64bit kernel with a 64bit userspace atm.
>>> But if I'm wrong I'd of course love to hear about it :)
>>>
>>>
>>
>> Has anyone done any actual benchmark tests that show 64-bit vs 32-bit
>> environments/distributions with Athlon64 processors. If so, I love
>> to see the results. I too elected to stick with 32-bit, using the
>> same reasoning/guessing above.
>
>
> remember that benchmarks are all dependant on your workload, but on
> some of my workloads (lots of fork-based network services) I've seen a
> 50%+ increase by switching from a 32 bit to 64 bit kernel with 32 bit
> userspace, and a further 50%+ increase by switching to a 64 bit
> userspace.
>
Thanks for your response. I'm prob. being stupid here... but does
"increase" here mean faster or slower?
> remember that on amd64 systems 64 bit programs have access to twice as
> many registers as 32 bit programs. This can be more of a win then the
> extra pointer size is a loss.
If you've done other "standard" type of benchmarks between the two
please post your results. Also, is there a big hit by using a nearly
pure 32-bit environment + the rare 64-bit program when needed?
--
Jeffrey Hundstad
next prev parent reply other threads:[~2006-01-10 20:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-09 20:18 Athlon 64 X2 cpuinfo oddities Jesper Juhl
2006-01-09 20:29 ` Dave Dillow
2006-01-09 22:49 ` Jesper Juhl
2006-01-09 21:10 ` Rafael J. Wysocki
2006-01-09 22:32 ` Edmondo Tommasina
2006-01-09 22:41 ` Jesper Juhl
2006-01-09 22:49 ` Edmondo Tommasina
2006-01-10 1:49 ` Andi Kleen
2006-01-10 2:12 ` Jesper Juhl
2006-01-10 2:36 ` Andi Kleen
2006-01-10 9:29 ` Jesper Juhl
2006-01-10 20:23 ` 64-bit vs 32-bit userspace/kernel benchmark? Was: " Jeffrey Hundstad
2006-01-10 20:34 ` 64-bit vs 32-bit userspace/kernel benchmark? Was: Athlon 64 X2 cpuinfooddities David Lang
2006-01-10 20:50 ` Jeffrey Hundstad [this message]
2006-01-10 20:53 ` 64-bit vs 32-bit userspace/kernel benchmark? Was: Athlon 64 X2cpuinfooddities David Lang
2006-01-10 20:55 ` 64-bit vs 32-bit userspace/kernel benchmark? Was: Athlon 64 X2 cpuinfo oddities Andi Kleen
2006-01-11 0:15 ` Ken Moffat
2006-02-13 2:53 ` Brandon Low
2006-02-13 3:00 ` Alistair John Strachan
2006-02-13 9:20 ` Andi Kleen
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=43C41DFD.9000507@mnsu.edu \
--to=jeffrey.hundstad@mnsu.edu \
--cc=ak@suse.de \
--cc=dlang@digitalinsight.com \
--cc=jesper.juhl@gmail.com \
--cc=linux-kernel@vger.kernel.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 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.