SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Politics : Formerly About Advanced Micro Devices -- Ignore unavailable to you. Want to Upgrade?


To: Paul Engel who wrote (80209)11/17/1999 1:39:00 AM
From: Elmer  Respond to of 1571546
 
Re: "Hey....I haven't seen Tejerk post one of his "AThWIPE - the FASTEST PROCESSOR iN THE WORLD" posts in a while."

Wasn't it Steve Harris?

Maybe Cringe will come back on defending the Athlon with those phoney marketing foils again.... The ones with no benchmark numbers and no system configurations, but that didn't keep him from being convinced they were genuine and totally accurate.

EP



To: Paul Engel who wrote (80209)11/17/1999 2:03:00 AM
From: Petz  Read Replies (2) | Respond to of 1571546
 
Engel, re:<FlopperMine's high SPECint scores>
AMD can play this cheating game too, by implementing a pre-fetch compiler and I suspect they will. Such compilers are useless for real programs because they are specific not just to the CPU being used but also the chipset and memory system. For example, the prefetch instructions for an i820 mobo/600 MHz RDRAM combo could actually harm execution on an overclocked BX chipset or an i840 mobo with two channels of RDRAM.

Without a pre-fetching compiler the CuMine is only 1% faster clock for clock in SPECint and 17% slower in SPECfp. I quote from x33.deja.com
----------------
Prefetch-free Spec scores from JC:

"Mmmmm ... thanks to Armand Hirt for letting me know, the spec scores reported by c't for the Coppermine:
With Intel's latest non-prefetch compiler (Intel C compiler V 4.0), Coppermine-733 with PC800 DRDRAM on i820 (which should be out by Comdex or shortly thereafter?) scores a 32.8 in specint, 5.8% higher than the 31.0 of Athlon-700. As a quick back of the envelope calculation, since specint increases very linearly in my experience, this makes Coppermine/i820/PC800 1% faster, clock for clock, at specint over Athlon/AMD750/PC100. With Intel's latest non-prefetch compiler for specfp (Intel Fortran V 2.4), Coppermine/i820/PC800 @ 733MHz gets 19.5 compared to the Athlon/AMD750/PC100's 22.3, giving the Athlon a mild 14.4% lead (which probably expands to about a 17.1% lead if you somehow convinced the Athlon to run at 733MHz with that 100MHz memory -- eg, clock for clock). Armand mentions that he is not totally sure that these latest compilers have no prefetch usage (though from the scores I'd imagine that they do not)."
----------------
Now for the rest of the post which makes my original point, that pre-fetch compilers are specific not just to the CPU but to the chipset and memory system as well:

"Trouble with prefetch is that its not that useful when used indiscriminately. Where and when to place the prefetches is dependant on the characteristics of the memory system. So the Intel 4.5 compiler has to know about the details of the system its running on, not just the CPU. Not much good if you're compiling the next 1-2-3 spreadsheet that you hope will sell 10 million copies. OK if you have source code but no good for distribution of binaries. How does SPEC handle this, anyone know? The SPEC scores that Intel is posting only refer to precisely the reference platform. Taking the same binary and running it on any other system could well introduce prefetch penalties (extra code but no benefits)."

Here's another quote from later in this thread:
"I suspect that the smarts in the new Intel compiler are heavily geared towards the SPECfp95 suite and won't be very robust on different types of FP code (e.g. 3D rendering). I
also wonder if indiscriminate use of prefetch will hurt the performance of some code as much as it helps SPECfp95."

Petz