Re: Plan 9 grids with AMD64 CPUs

Charles Forsyth wrote:
> in short, apart from artificial benchmarks, what improvements
> do people see on real applications and just as important,
> what actually makes the difference?
> 
> another justification i've seen that does make sense is to use 64-bit addressing for
> applications that need a huge directly-addressible memory (not that there
> are too many of those applications, or that they couldn't be a bit cleverer).

We had a customer that does statistical analysis for VLSI and he needed 
32G of RAM to run efficiently. Just assume that there are a couple 
of applications out there nowadays that are demanding more RAM...

SuSE came up with the first Linux distribution supporting the opterons in 64 bit
mode, and they claim they found:
 * 8 extra registers in 64bit mode can be used to toolchains advantage
 * improved calling conventions where function arguments are passed in 
   registers and not on the stack.
 * fewer architectural instructions for the same source code. 
   Code tends to stay within 10% of 32bit x86 code. 
   Main reason for larger code is longer instructions. Number of instructions 
   itself decreases by about 10%. Fewer instructions means faster execution.
 * usage of SSE2 unit for floatpoint arithmetic with flat 16 register file
   instead of x87 FPU with its cumbersome register stack.
 * bigger address space means less IO ops. (?)
 * SuSE uses syscall (faster than int 0x80) instruction in kernel and libc).

Source: http://www.suse.com/en/business/products/server/sles/sles8_amd64.pdf 

In real live we have only pitched the opteron in 64bit mode against the xeon in 
32bit mode, and there it almost always wins, especially when more than one CPU 
does something memory-intensive, since they don't have to share a frontside-bus 
but rather each CPU has its own direct access to its own RAM DIMMS, and 
can access other CPUS DIMMS via Hypertransport (6.4GB/s).

http://www6.tomshardware.com/cpu/20030422/opteron-17.html has some real-world 
benchmarks as well as http://www.aceshardware.com/read.jsp?id=55000261 which 
shows how it affects performance of a MySQL database.

Here some highly unscientific benchmark numbers where we pitched 
a 4-CPU Xeon-MP 2Ghz (512k Cache) with 4G RAM 
vs. 
a 2-CPU Opteron242 1.6Ghz (1024k Cache) with 1G RAM.

| benchmark |  unit | Xeon-MP 4CPU | Opteron242 2CPU| benchmarktype
+-----------+-------+--------------+----------------+--------------
| Drystones |       |   1488833    | 2325581        | serial
| Whetstones|  MIPS |  384.6       | 1111.1         | serial
| mem-Copy  |  MB/s | 1079.2603    | 1430.8743      | serial
| mem-Scale |  MB/s | 1032.3950    | 1317.4114      | serial
| mem-Add   |  MB/s | 1338.7658    | 1267.1572      | serial
| mem-Triad |  MB/s | 1233.6161    | 1479.4741      | serial
| lpc-dpr   | Mflops|   435.11     | 418.93         | parallel
| lpc-spu   | Mflops|   102.80     | 345.10         | parallel

Interesting that mem-add is faster for the xeon. Any idea why?

Michael Will
-- 
Michael Will, Linux Sales Engineer
Tel:  415-945-2822  Toll Free:  888-PENGUIN
PENGUIN COMPUTING - The World's Most Reliable Linux System
www.penguincomputing.com