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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox