Re: confused about performance
Leopold Palomo-Avellaneda wrote:
> A Dijous 14 Juny 2007 15:21, Lennart Sorensen va escriure:
>> On Wed, Jun 13, 2007 at 04:40:52PM -0600, Sebastian Kuzminsky wrote:
>>> Hi folks, I just bought a pair of AMD64 systems for a work project,
>>> and I'm confused about the performance I'm getting from them. Both are
>>> identically configured Dell Dimension C521 systems, with Athlon 64 X2
>>> 3800+ CPUs and 1 GB RAM.
>>> On one I installed using the Etch (4.0r0) i386 netinst CD, then upgraded
>>> to Lenny. This one's running linux-image-2.6.21-1-686.
>>> On the other I installed using the current (as of 2007-06-13) Lenny d-i
>>> amd64 snapshot netinst CD. This one's running
>>> The one with the x86 userspace and 686 kernel is faster than the one
>>> with x86_64 userspace and amd64 kernel. The difference is consistently
>>> a few percent in favor of x86 over x86_64.
>>> My only benchmark is compiling our internal source tree (mostly running
>>> gcc, some g++, flex, bison, etc). We're using gcc-4.1 and g++-4.1.
>>> I've tried it with a cold disk cache and hot disk cache, in both cases
>>> x86 is faster than x86_64.
>>> I was expecting a win for 64 bit. What's going on here?
>> 64 bit is faster at some things. For things like gcc you may simply be
>> gaining nothing and loosing a few percent due to having to move around 8
>> bytes per pointer rather than 4 bytes per pointer. Certainly on sparc64
>> I believe that is known to cause a slight slow down. On sparc most
>> programs are 32bit I believe, with only a few specific ones that gain
>> from 64bit (like lots of ram) are compiled for 64 bit.
>> Now anything using floating point should gain significantly on 64bit.
>> Of course none of your list of tests do. SSE (the only floating point
>> used on x86_64) is much faster than the old stack based x87
>> There are also some programs that gain some performance benefit from the
>> extra registers that you get in 64bit mode, but for most programs it
>> probably doesn't really matter. gcc may also not be very good at using
>> those extra registers yet.
>> Of course if you need more than about 3GB ram in your system, 64bit will
>> probably win simply by avoiding the (not insignificant) overhead of PAE
>> (needed to access more than 4GB address space on x86). Also if a
>> program can take advantage of more than 2 or 3GB ram by itself, on 64bit
>> you can use however much ram you have for the application, while on x86
>> you are limited to 3GB ram per application.
> really, reading you makes me doubt about the whole port. How many apps do we
> have in the debian pool that can win some kind of performance?
1. 32-bit isn't going away. The new chips are all going to be
64-bit-capable (and virtualization-capable, multi-core, etc.) but the
software is going to lag that.
2. There are two reasons you'd want a 64-bit machine:
a. You have a production application that *needs* a 64-bit machine.
For the moment, most but not all of those are high-performance
b. You want to develop 64-bit applications
3. I've got an Athlon64 X2 (64 bit, dual-core, virtualization capable).
I'm running a 64-bit OS (Gentoo, although Etch works just fine on it). I
haven't done any 32-bit vs. 64-bit benchmarking or GCC benchmarking on
it because quite frankly, I think such efforts are wasted and
irrelevant. I got the machine for b. above -- I want to develop 64-bit
multi-core virtualization-aware applications.
As far as the applications in the Debian pool, or open source in
general, are concerned, I would first look at large-scale scientific
computing. And I would start with making sure that you have the Atlas
(automatically tuned linear algebra subroutines) libraries and their
BLAS and LAPACK interfaces all tuned up and ready to install on all the
architectures. The ATLAS team is just about ready to release 3.8 -- they
are at 3.7.32 at the moment and I think what's in Debian is still 3.6.0.
The last test I ran on my Athlon64 X2 4200+ (2.2 GHz) got me about 10
gigaflops in 32-bit arithmetic and about half of that in 64-bit arithmetic.