drafts of write-ups on 9.2.0rc8 perf
raj at cup.hp.com
Tue Nov 6 23:54:32 UTC 2001
Brad Knowles wrote:
> At 12:31 PM -0800 11/6/01, Rick Jones wrote:
> > ftp://ftp.cup.hp.com/dist/networking/briefs/compet_server_results.txt
> Note that what's available on the server is the 0.1 version
> of this file.
That's correct. The rev mumble will go up there after folks here have
had a chance to give their feedback.
> > Named Performance Summary
> > netperf DNS_RR test requesting 1000 out of cup.hp.com
> > 8.1.2 8.2.2-P5 9.2.0rc8 9.2.0rc8
> > "Sun" "Sun" "stock" "-fast"
> > System +====================================================
> > UE420 1x450 | 4,272 | | | |
> > UE420 2x450 | 4,700 | | | |
> > UE420 4x450 | 5,156 | | | |
> > B1750 1x750 | | 5,586 | 1,225 | 2,336 |
> > +====================================================
> Hmm. You didn't build your own version of 8.2.x for Sun with
> the professional compiler, etc...? I'm not sure that the results
> will be completely comparable to the detailed analysis that you've
> done for HP, although you could always use the less optimized results.
I was mostly after a comparison between 8 and 9 on the same Sun
hardware. It was easiest to take what Sun ships and use it.
> > and will enable appropriate optimizations. The "-fast" flag was used in
> > Sun's SPECcpu2000 submittals for the Blade 1750. The method used to
> > cause "-fast" to be set was:
> Was this gcc or the Sun professional compiler?
Good question. It was the Forte 6.2 compiler. I will add that to the
> > Rare data:
> > The "threads" in these data represent separate, synchronous,
> > streams of requests. The data presented here is the summary of the
> > raw data collected. If you are keenly interested in the minutiae,
> > you can contact the author.
> I'm curious do you mean "rare data" as the title for this
> section, or "raw data"? And what about testing with a UE280R, as
> compared to the Blade 1750?
The raw data are the results of the individual streams of requests. I
have them archived, but not published. Each stream was getting basically
the same ops/sec as any other stream so the data would not be terribly
interesting - it would only make the file larger. I call it "rare" data
because it is post-processed from the raw data.
If I had a UE280R I would be more than happy to use it. I have a
_number_ of things I would like to run on a 280R :) The Blade 1750 is
what I happened to have available to me, and it too is about to pumpkin
on me. From what little I do know about the two systems, I would expect
the performance of the systems to be about the same.
> > A "full" binary is a 64 bit PA 2.0 binary compiled with +DA2.0W and
> > includes Profile Based Optimization (PBO - +I/+P), +O4,
> > +Ostaticprediction and +Oentrysched. It also includes the use of
> > the
> > chatr utility to set the default instruction and data page sizes to
> > "L" for largest possible. A full binary was not created for this
> > writeup.
> I'm curious -- is there a particular reason why a "full"
> binary wasn't created for this run?
Yes. BIND 9's need to use that blessed "gen" utility while compiling.
The HP compiler gets rather cranky when one asks it to use profiling
data in compilation and there is no profile data for a given binary. I
can get enough profile data for everything other than gen by just
running each binary with a -? option - it adds to the "flow.data" file
used by the compiler. However, that does not seem to work with gen - gen
gets recreated each time and the way that happens makes the compiler
complain that the profile data does not match the source and it stops.
This didn't happen with BIND 8.
I _thought_ I worked around that somehow with 9.1. I think it might have
been by hand-editing the makefiles after a configure. I have to decide
if that would be worth all the trouble.
> > j6700 2x750 MHz 8.2.5 "O3" :
> [ ... deletia ... ]
> > j6700 2x750 MHz 8.2.5 "O3" :
> I'm confused. These last two sections appear to have
> precisely the same title. Was on an "O3" and the other an "O4", or
> are we comparing 8.2.5 versus 9.2.0rc8 here?
Cut and paste bug. The second one should be O4. I'll update the file
> Otherwise, this is extremely interesting and illuminating
> testing that you have done -- as per usual. Thanks for all the work
> you've done in this area for so long!
I only mentioned it tangentially, but the warmup time for bind 8 was
much much longer than for bind 9. that suggests there are certain
situations where "basic" (perhaps uncached) lookups would have higher
throughput on bind 9 but i'm not quite sure how to go about
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...
More information about the bind-workers