Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

i386 vs amd64 - benchmark results

14 views
Skip to first unread message

Martin

unread,
Jul 26, 2005, 1:58:11 PM7/26/05
to

Hi,

I've tried two benchmarks to check the speed of my
system on two FreeBSD architectures i386 and amd64.
I've never seen anyone posting this kind of benchmark,
so here is what I found out:

here the results of nbench:
http://phpfi.com/71540

here is what openssl speed gives me:
http://phpfi.com/71545

Sorry for posting it there, but I don't want to
send attachments to this list.

Please notice the memory speed penalties while the
system is running on amd64 kernel. I would like to
know what causes this kind of low performance when
memory is being accessed.

Is this a hardware problem or a problem with FreeBSD?
Generally, FreeBSD-amd64 performs slightly better
than FreeBSD-i386 and it's stable as expected, but
I cannot find any solution to the memory problems
that affect memory intensive applications as you can
see.

Martin

_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

Björn König

unread,
Jul 26, 2005, 8:54:01 PM7/26/05
to
You might want to have a look at my private benchmarks too:

http://www.alpha-tierchen.de/dateien/etc/benchmark.html

Björn

Martin

unread,
Jul 27, 2005, 2:20:07 AM7/27/05
to
Björn König wrote:
> You might want to have a look at my private benchmarks too:
>
> http://www.alpha-tierchen.de/dateien/etc/benchmark.html

Hmmm... your benchmarks show the same effect as I have on 5.4.

But I'm impressed by the RELENG_6 results. I think I'm going to
upgrade my system instantly.

Martin

Roland Smith

unread,
Jul 27, 2005, 5:49:26 AM7/27/05
to

--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 26, 2005 at 07:57:06PM +0200, Martin wrote:
>=20
> Hi,
>=20


> I've tried two benchmarks to check the speed of my
> system on two FreeBSD architectures i386 and amd64.

My results for amd64 (haven't tried i386):

Hardware:
Athlon64 3400+ (2.4 GHz, 400 MHz FSB)
MSI Neo FSR (MSI-6702)
2x512 MB PC3200U-2533 RAM

TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 1684.8 : 43.21 : 14.19
STRING SORT : 186.1 : 83.15 : 12.87
BITFIELD : 3.9649e+08 : 68.01 : 14.21
FP EMULATION : 134.38 : 64.48 : 14.88
FOURIER : 17671 : 20.10 : 11.29
ASSIGNMENT : 22.259 : 84.70 : 21.97
IDEA : 3618.9 : 55.35 : 16.43
HUFFMAN : 1626.1 : 45.09 : 14.40
NEURAL NET : 25.743 : 41.35 : 17.39
LU DECOMPOSITION : 1156.3 : 59.90 : 43.26
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3DORIGINAL BYTEMARK RESULTS=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
INTEGER INDEX : 61.508
FLOATING-POINT INDEX: 36.786
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3DLINUX DATA BELOW=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CPU :=20
L2 Cache :=20
OS : FreeBSD 5.4-STABLE
C compiler : cc
libc : /lib/libc.so.5
MEMORY INDEX : 15.896
INTEGER INDEX : 14.951
FLOATING-POINT INDEX: 20.403
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

Roland
--=20
R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text.
public key: http://www.xs4all.nl/~rsmith/pubkey.txt

--tThc/1wpZn/ma/RB
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)

iD8DBQFC51h1EnfvsMMhpyURApXvAKCFzWG7vegorubk1yDHPm4yib1oqQCgiOL2
8jGh02soY+Sh6N096dXl57c=
=p6cs
-----END PGP SIGNATURE-----

--tThc/1wpZn/ma/RB--

Björn König

unread,
Jul 27, 2005, 8:06:27 AM7/27/05
to
Martin wrote:

> But I'm impressed by the RELENG_6 results. I think I'm going to
> upgrade my system instantly.

Yes, the results are slightly better, even the support of amd64 appears
to be much better, but I would be careful; it's easy to overrate
benchmark results. There is a lot that you can do wrong if you create
benchmarks and I would not guarantee for the correctness of my own
results. Nevertheless I think 6.0 will be a great release with increased
performance.

Björn

Vivek Khera

unread,
Jul 27, 2005, 11:54:28 AM7/27/05
to

--Apple-Mail-2-290946002
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed


On Jul 26, 2005, at 1:57 PM, Martin wrote:

> Please notice the memory speed penalties while the
> system is running on amd64 kernel. I would like to
> know what causes this kind of low performance when
> memory is being accessed.

The amd64 memory architecture is NUMA -- that is, depending on how
your RAM is layed out, some of it is faster to access for each
processor. Accessing RAM "local" to the other processor(s) is slower.

There are many subtle issues relating to non-uniform memory access
and how to code programs to take advantage of it (or try to avoid
being bit by it). It is a very hard problem, and the three letters
following my name came to be from researching this issue 11 years
ago :-)

The FreeBSD scheduler and memory allocators are definitely not NUMA
aware.

Vivek Khera, Ph.D.
+1-301-869-4449 x806

--Apple-Mail-2-290946002--

Charles Swiger

unread,
Jul 27, 2005, 12:18:57 PM7/27/05
to
On Jul 27, 2005, at 11:52 AM, Vivek Khera wrote:
> The amd64 memory architecture is NUMA -- that is, depending on how
> your RAM is layed out, some of it is faster to access for each
> processor. Accessing RAM "local" to the other processor(s) is slower.
>
> There are many subtle issues relating to non-uniform memory access
> and how to code programs to take advantage of it (or try to avoid
> being bit by it). It is a very hard problem, and the three letters
> following my name came to be from researching this issue 11 years
> ago :-)
>
> The FreeBSD scheduler and memory allocators are definitely not NUMA
> aware.

No, although there appears to be some integration of concepts like
"virtual memory objects" and binary format branding into FreeBSD from
Mach, which did make efforts to support assymmetric multiprocessing,
heterogenous processor types in one box, and NUMA memory architecture.

It is a really hard problem to deal with :-), and you tend to end up
with processors that could do specific things very quickly, if only
the communications bandwidth between them and other CPUs was fast
enough that the cost of distributing work around exceeds the benefits
of allocating the right processor for a specific job.

I suspect that FreeBSD is going to deal more with this in the context
of x86 or AMD64 hardware which has a fancy GPU, maybe a smart RAID
controller, and the specialized NIC hardware which can handle more of
the TCP/IP stack (not just computing checksums, but handling IPsec,
VLAN or other encapsulation of frames, doing IP fragment reassembly,
or even higher layer stuff), then with a couple of 68040's glued to a
56001 DSP, with i960's running on the Dimension boards...

--
-Chuck

Bob Willcox

unread,
Jul 27, 2005, 3:41:24 PM7/27/05
to
On Tue, Jul 26, 2005 at 07:57:06PM +0200, Martin wrote:
>
> Hi,

>
> I've tried two benchmarks to check the speed of my
> system on two FreeBSD architectures i386 and amd64.
> I've never seen anyone posting this kind of benchmark,
> so here is what I found out:
>
> here the results of nbench:
> http://phpfi.com/71540
>
> here is what openssl speed gives me:
> http://phpfi.com/71545
>
> Sorry for posting it there, but I don't want to
> send attachments to this list.
>
> Please notice the memory speed penalties while the
> system is running on amd64 kernel. I would like to
> know what causes this kind of low performance when
> memory is being accessed.
>
> Is this a hardware problem or a problem with FreeBSD?
> Generally, FreeBSD-amd64 performs slightly better
> than FreeBSD-i386 and it's stable as expected, but
> I cannot find any solution to the memory problems
> that affect memory intensive applications as you can
> see.
>
> Martin

As another data point, below is the nbench output from one of my
systems. It's an Athlon 64 3800+ w/ venice core running FreeBSD
6.0-BETA1. Motherboard is an ASUS A8V Deluxe (socket 939) with 1GB of
DDR400 RAM (2 512MB sticks).

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------

NUMERIC SORT : 2326 : 59.65 : 19.59
STRING SORT : 202.35 : 90.41 : 13.99
BITFIELD : 5.2938e+08 : 90.81 : 18.97
FP EMULATION : 153.36 : 73.59 : 16.98
FOURIER : 18608 : 21.16 : 11.89
ASSIGNMENT : 27.817 : 105.85 : 27.46
IDEA : 3400 : 52.00 : 15.44
HUFFMAN : 1869.4 : 51.84 : 16.55
NEURAL NET : 24.696 : 39.67 : 16.69
LU DECOMPOSITION : 1237.9 : 64.13 : 46.31
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 72.257
FLOATING-POINT INDEX: 37.759


Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0

==============================LINUX DATA BELOW===============================
CPU :
L2 Cache :
OS : FreeBSD 6.0-BETA1
C compiler : cc
libc : /lib/libc.so.6
MEMORY INDEX : 19.388
INTEGER INDEX : 17.076
FLOATING-POINT INDEX: 20.942


Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

* Trademarks are property of their respective holder.

--
Bob Willcox Reality is nothing but a collective hunch.
b...@immure.com -- Lily Tomlin
Austin, TX

0 new messages