Athlon 64 3400 vs Opteron 148

Athlon 64 3400 vs Opteron 148

[Grumble]

As far as I can tell, the Athlon 64 3400 and the Opteron 148 are quite 
similar. They both run at 2.2 GHz, and both have a 1 MB L2 cache.

The two (minor) differences are:

   Registered vs Unbuffered RAM
   Dual-Channel vs Single-Channel memory controller

I have access to a Mobile Athlon 64 3400:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 4
model name      : AMD Athlon(tm) 64 Processor 3400+
stepping        : 8
cpu MHz         : 2200.137
cache size      : 1024 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 
3dnowext 3dnow
bogomips        : 4336.64
TLB size        : 1088 4K pages
clflush size    : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp


SPEC CINT2000 Result for AMD's Opteron 148:
http://www.specbench.org/osg/cpu2000/results/res2003q4/cpu2000-20031117-02631.html

So far, I have only run mcf.

http://www.spec.org/cpu2000/CINT2000/181.mcf/docs/181.mcf.html

I am disappointed because my results are worse than AMD's. On the 
Opteron, mcf base took 250 seconds to complete. On the Athlon 64, mcf 
base took 316 seconds (26.4% slower) to complete.

I used gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-24) while AMD 
used SuSE gcc 3.3.1 compiler (from SuSE Linux 9.0).

What could explain the large difference? Did gcc improve that much 
between 3.2 and 3.3? I've read that registered RAM is actually slower 
than unbuffered RAM. Would the dual-channel help?

SPEC's mcf run requires 190 MB of memory.

http://www.spec.org/cpu2000/analysis/memory/

-- 
Regards, Grumble

Re: Athlon 64 3400 vs Opteron 148

[llewelly]

Grumble <invalid@kma.eu.org> writes:

> As far as I can tell, the Athlon 64 3400 and the Opteron 148 are quite
> similar. They both run at 2.2 GHz, and both have a 1 MB L2 cache.
> 
> The two (minor) differences are:
> 
>    Registered vs Unbuffered RAM
>    Dual-Channel vs Single-Channel memory controller
> 
> I have access to a Mobile Athlon 64 3400:
> 
> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 15
> model           : 4
> model name      : AMD Athlon(tm) 64 Processor 3400+
> stepping        : 8
> cpu MHz         : 2200.137
> cache size      : 1024 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 1
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm
> 3dnowext 3dnow
> bogomips        : 4336.64
> TLB size        : 1088 4K pages
> clflush size    : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management: ts fid vid ttp
> 
> 
> SPEC CINT2000 Result for AMD's Opteron 148:
> http://www.specbench.org/osg/cpu2000/results/res2003q4/cpu2000-20031117-02631.html
> 
> So far, I have only run mcf.
> 
> http://www.spec.org/cpu2000/CINT2000/181.mcf/docs/181.mcf.html
> 
> I am disappointed because my results are worse than AMD's. On the
> Opteron, mcf base took 250 seconds to complete. On the Athlon 64, mcf
> base took 316 seconds (26.4% slower) to complete.
> 
> I used gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-24) while AMD
> used SuSE gcc 3.3.1 compiler (from SuSE Linux 9.0).
> 
> What could explain the large difference? Did gcc improve that much
> between 3.2 and 3.3?

From gcc.gnu.org/gcc-3.3/changes.html :

  * The following changes have been made to the IA-32/x86-64 port:
      + SSE2 and 3dNOW! intrinsics are now supported.
      + Support for thread local storage has been added to the IA-32
      and x86-64 ports.
      + The x86-64 port has been significantly improved.
 
The only way to know for sure, however, is download the source for
    SuSE gcc 3.3.1 (note, linux distro gcc releases generally differ
    slightly from vanilla FSF releases with the same version number.),
    build it, and test it. 

Note that compiler flags can make a substantial difference as well,
    and sometimes in surprising ways; see
    http://www.coyotegulch.com/acovea/acovea_4.html for an example
    with a different version of gcc.


> I've read that registered RAM is actually slower
> than unbuffered RAM. Would the dual-channel help?
[snip]

In the most extreme case, dual-channel could double performance (this
    would be for code that is bound solely by memory bandwidth). This
    situation is probably very rare, however.