Benchmarks: AMD64 vs i386 on Dual 246 Opteron

[Ken Gunderson]

On Thu, 28 Jul 2005 19:35:19 -0400
Martin Cracauer <cracauer at cons.org> wrote:

> > While this sounded like a long shot, I loaded FreeBSD 5.4 i386 on the machine
> > and after applying the exact same configuration to the OS, Apache, PHP and
> > MySQL, re-ran the benchmarks.  Much to my surprise, just changing the OS from 64
> > bit to 32 bit caused the machine to double in speed.  The results are attached
> > in an Excel spreadsheet.  So the exact same machine, running the identical
> > configuration, performed roughly twice as fast when running FreeBSD 5.4 i386 vs
> > FreeBSD 5.4 AMD64.  Something about this seems so wrong to me :-)
> 
> I'm sorry but I cannot support these findings.  I don't have
> cut'n'paste numbers handy, but generally 64 bits speed up things quite
> a bit for me.  I have seen slowdown in 64 bit mode in e.g. bzip2 but
> generally there is a speedup.
> 
> Data is not generally doubled in size.  Plain int stays the same in C.
> Floating point stays the same.  String stays the same.  Arrays of ints
> stay the same.  But e.g. lists do not.

In another context I just happened to be running some Apache Bench
tests on a couple systems earlier today;

1) Dual opteron 246 w/4GB DDR400 ECC Registered Memory:

Server Software:        lighttpd/1.3.15
Server Hostname:        typo.mydom.tld
Server Port:            80

Document Path:          /
Document Length:        2846 bytes

Concurrency Level:      1000
Time taken for tests:   13.998918 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      3065062 bytes
HTML transferred:       2848846 bytes
Requests per second:    71.43 [#/sec] (mean)
Time per request:       13998.918 [ms] (mean)
Time per request:       13.999 [ms] (mean, across all concurrent
requests) Transfer rate:          213.80 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2 1644 3065.3      2    9414
Processing:   330 2270 654.8   2181    4046
Waiting:      323 2267 654.9   2179    4042
Total:        477 3914 3442.4   2465   13445

2) And w/legacy 700 MHz PIII w/1GB PC100 Memory (or maybe its PC133, I
don't exactly recall):

$ ab -n 1000 -c 1000 http://typo.mydom.tld/

Server Software:        lighttpd/1.3.15
Server Hostname:        typo.mydom.tld
Server Port:            80

Document Path:          /
Document Length:        7951 bytes

Concurrency Level:      1000
Time taken for tests:   7.122140 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      8750272 bytes
HTML transferred:       8493032 bytes
Requests per second:    140.41 [#/sec] (mean)
Time per request:       7122.140 [ms] (mean)
Time per request:       7.122 [ms] (mean, across all concurrent
requests) Transfer rate:          1199.78 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2  434 1091.0      2    6205
Processing:   133 1036 295.6   1034    2152
Waiting:      130  788 209.6    805    1381
Total:        287 1471 1126.9   1108    7076

No efforts were made to optimize or tune anything.  This is an ROR app
running under FastCGI via Lighttpd proxied by Apache2.  Lighttpd.conf
spec'd max-procs=4.  Both machines running FBSD-5.4-p5.  Opteron box
running amd64.  Results are same w/wo the Apache proxy so it's not the
bottleneck.

FWIW we see that the lowly PIII serves up roughly 2x the requests/
second (w/larger requests even) than the "64 bit AMD Goliath". 

Of course the Opteron totally spanks the 700MHz on Ubench scores.  Not
trying to start any wars, just throwing this out for what it's worth
since my quick tests just happened to concur with the timing of this
thead....

-- 
Best regards,

Ken Gunderson

Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?