From: Kurt Fitzner <kfitzner@excelcia.org>
To: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] B132L outperforms C160 - 64-bit userland needed?
Date: Wed, 17 Aug 2005 23:27:24 -0600 [thread overview]
Message-ID: <43041C3C.2080704@excelcia.org> (raw)
In-Reply-To: <20050817194058.GA3378@netfall.com>
Andrew Sharp wrote:
> So stop ignoring that difference. Cache thrashing is
> a real, and sad, international problem. Take those benchmarks that
> produce slower results on a P4/2MB cache processor than they do on a
> P4/512KB processor. Same motherboard, OS, benchmark. Only difference,
> 4x bigger cache. If the processor is spending more time loading cache
> lines, it's spending less time computating. Cache systems are designed to
> improve the performance of general computing tasks, and many benchmarks
> fall outside that realm.
Andrew Sharp wrote:
Ok, I bit the bullet. I took an image of the hard drive to restore
later, and installed HPUX. I then obtained gcc 3.4.3 from the HPUX
software porting archive and recompiled the benchmark with that. Raw
data is at the end.
Next off, for nbench running on a C160/HPUX I see a memory throughput
increase of 2.67X, integer calc increase of 1.4X, and floating point
increase of 2.24X when compared to the C160/Linux.
The data show exactly the sort of performance increase that I originally
expected to see when comparing a B132L and C160. Strongly improved
integer and vastly improved memory performance.
The performance issue on my C160/Linux was not due cache line
loading/thrashing. It's not due to slower memory, nor due to some odd
conflaguration of C160 architecture changes and an old benchmark
program. I am convinced that there is some problem in Linux - probably
some otherwise minor thing. Whatever it is, it's sucking performance
from PA8000 systems - and perhaps other PA8x00 ones.
What really locked it in for me that it's an OS issue, aside from the
dramatic results below, is what happened when I changed optimization
switches in HPUX. I see the exact same 2% drop in performance when I go
from binaries compiled as 1.1/7300 to 2.0/8000 that I saw in Linux.
Same compiler on both OSes producing code that reacts exactly the same
way when optimizations are changed.
I'm convinced - how can I convince the group? I'm quite willing to give
ssh access to my machines for the results to be verified. I should be
able to swap between HPUX/Linux fairly quickly now that I have images of
both.
Kurt.
p.s. I installed HPUX in 64-bit mode. Which, so I'm told, should have
decreased my performance. I'd like to get my C160 running Linux in
64-bit mode, but I can't. :(
------------------------------------------------------------------
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 99.68 : 2.56 : 0.84
STRING SORT : 14.104 : 6.30 : 0.98
BITFIELD : 2.1599e+07 : 3.70 : 0.77
FP EMULATION : 8.8339 : 4.24 : 0.98
FOURIER : 2660.2 : 3.03 : 1.70
ASSIGNMENT : 1.8832 : 7.17 : 1.86
IDEA : 116.73 : 1.79 : 0.53
HUFFMAN : 121.4 : 3.37 : 1.08
NEURAL NET : 2.81 : 4.51 : 1.90
LU DECOMPOSITION : 116.6 : 6.04 : 4.36
==================================================================
OS : HP-UX B.11.11
C compiler : gcc version 3.4.3
MEMORY INDEX : 1.120
INTEGER INDEX : 0.827
FLOATING-POINT INDEX: 2.414
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
next prev parent reply other threads:[~2005-08-18 5:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-16 9:23 [parisc-linux] B132L outperforms C160 - 64-bit userland needed? Kurt Fitzner
2005-08-16 13:00 ` Michael S. Zick
2005-08-17 0:03 ` Kurt Fitzner
2005-08-17 1:32 ` John David Anglin
2005-08-17 1:48 ` Michael S. Zick
2005-08-17 3:43 ` Kurt Fitzner
2005-08-17 6:37 ` Grant Grundler
2005-08-17 14:16 ` John David Anglin
2005-08-17 6:19 ` Grant Grundler
2005-08-17 18:42 ` Kurt Fitzner
2005-08-17 18:56 ` Kyle McMartin
2005-08-17 19:40 ` Andrew Sharp
2005-08-18 5:27 ` Kurt Fitzner [this message]
2005-08-18 7:17 ` Grant Grundler
2005-08-20 6:21 ` Grant Grundler
2005-08-17 20:38 ` Carlos O'Donell
-- strict thread matches above, loose matches on Subject: below --
2005-08-18 8:27 Joel Soete
2005-08-20 6:26 ` Grant Grundler
[not found] ` <430778F2.8020406@tiscali.be>
[not found] ` <20050820234126.GA20524@colo.lackof.org>
2005-08-21 9:42 ` Joel Soete
[not found] ` <20050820235516.GE2756@parcelfarce.linux.theplanet.co.uk>
2005-08-21 10:29 ` Joel Soete
2005-08-21 14:19 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43041C3C.2080704@excelcia.org \
--to=kfitzner@excelcia.org \
--cc=parisc-linux@lists.parisc-linux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.