[RC5] P4 Speed Question
peter at llama.nslug.ns.ca
Fri Jun 15 01:14:06 EDT 2001
On Wed, Jun 13, 2001 at 05:30:30PM -0500, Ryan Malayter wrote:
> www.news.com reports a forthcoming DDR chipset from Intel for the P4, code
> named "Brookdale," Expected "early next year."
> But as you say, so the f*ck what... P4 performance sucks with P3-optimized
> code. But the P4 isn't all that bad of a CPU core... it's just a bad choice
> for the current Windows software market.
> The SPEC CPU2000 bechmarks, which are designed to resist hand-tuning, but
> allow for compiler instruction-order optimizations, show us some of the P4
> core's potential. (I know that there are still loopholes in SPEC's hand- or
> feedback- optimization rules. Manufacturers can exploit these to a degree,
> but CPU2000 is much stricter than CPU95 in this regard, and a new enough
> benchmark that Intel/AMD probably haven't had time to really juice up their
> compilers with CPU2000-specific optimizations. In any case, benchmarks like
> SPEC are really the only way to compare two different CPU architectures
It would be great if Intel juiced up their compiler for the SPEC
benchmarks, since some of the SPECint benchmarks are gcc, perl, and gzip. I
would _love_ to have those progs run faster!
> Cint200 Cfp2000
> Athalon 1.4/PC2100 DDR SDRAM 554 458
> Intel P4 1.4 Ghz/PC800 RDRAM 529 538
> As you can see, the P4 core fares well running P4-optimized code
> clock-for-clock with the Athalon. (AMD chose to use Intel's p3-optimized 5.0
> compilers, Intel used the same compiler with P4 flags set). These benchmarks
> were submitted by AMD and Intel themselves to SPEC, so you can bet they
> represent the best both companies could muster for their platforms.
Thanks for posting this. The SPEC numbers were one of the things that
contributed to my opinion that the P4 doesn't suck, it just isn't worth the
money for most people. I had forgotten about them, and only remembered my
opinion that a P4 would be nice to have, as long as I didn't have to pay for
it. (On a limited budget, dual (or more) CPU AMD machines probably get
you the most bang for the buck when buying multiple computers for e.g. a
cluster. The physics prof I'm working for has bought several dual P3 1GHz
machines as the start of his cluster.)
> Still, since most binary code today is P3-optimized, and the Athalon is
> designed for this code base, that's what I'd buy next week. But if/when MS
> and other vendors start optimizing instruction order for the P4, you're
> going to see the Athalon's current application-level speed advantage
> disappear. Intel is still, after all, the bully in the market, and they're
> going to make P4 optimization pretty cheap and for most x86 shrink-wrap
Any sane company should do anything necessary to get people to optimize
their programs for the company's hardware, regardless of what that hardware
is. 3DFX took this pretty far, with their GLIDE libraries which didn't even
let people's 3D progs work on other video cards. Once the rest of the field
caught up with them, they had to do OpenGL like every one else.
I think it would be really cool if Intel open-sourced their optimizer, so
it could be incorporated into gcc, and used to compile everything that gcc
can. Currently, their optimizer doesn't support all of GNU C, so you can't
compile the Linux kernel with it. I don't think Intel has too much to gain
by keeping the source for their compiler proprietary, and they certainly
make more work for themselves by trying to do everything. Besides, imagine
how much good karma that would earn them, as well as good-will from the
geeks who might very well have an influence on large buying decisions.
> Somewhat ironically, it's the Linux folks - who can recompile most of their
> software to their liking - that might find they actually like performance
> (maybe not price) of the P4 right now.
I pity the foo' who can't recompile her OS (apologies to Mr. T :). I don't
find it ironic at all, since one of the reasons for using a Free OS is that
you can do anything you want with it, and aren't dependent on any company to
get around to doing stuff for you. Could you explain what you meant there?
> Assuming, of course, that these Lunix
> folks have access to good P4-optimized compilers and script interpreters...
Oh, you mean this?
*BSD can run Linux binaries with a compatibility layer, so presumably you
could use Intel's compiler on those OSes. You might have to do some tricks
to produce *BSD binaries so you wouldn't need the compatibility layer to run
the resultant binaries. Probably just using a native linker would do it.
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter at llama.nslug. , ns.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BCE
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5