Author: Robert Hyatt
Date: 20:38:34 09/27/02
Go up one level in this thread
On September 27, 2002 at 12:12:19, Vincent Diepeveen wrote: >On September 26, 2002 at 11:16:06, Robert Hyatt wrote: > >>On September 26, 2002 at 08:35:19, Vincent Diepeveen wrote: >> >>>On September 26, 2002 at 08:22:14, Jorge Pichard wrote: >>> >>>>It is customary for intel to compare a higher clock CPU with a much lower clock >>>>AMD CPU, for Instance, the latest P4 2.8 Ghz vs AMD XP 2200 Ghz. Sure they give >>>>creidit to a better memory, but this type of comparison is like comparing Apples >>>>and Oranges. >>>> >>>>http://www.pcworld.com/news/article/0,aid,104165,00.asp >>> >>>Crafty at AMD XP2600+ 2.133ghz Epox 8KHA+ Motherboard and CL2 ddr ram: >>> 75.5 seconds base run time >>> >>>Crafty at 2.8Ghz P4 533Mhz bus and PC800-ECC RDRAM: >>> 93.5 seconds base run time >> >> >> >>Yes... But the Intel duals are blowing the AMD duals out of the >>water, totally.. >> >>AMD appears to win the "single cpu war" at the moment. But on the >>duals (and beyond) they are _way_ behind intel's performance. > >Speaking for DIEP, Fritz and many other programs which are tuned for >AMD now, the AMD annihilates the intel things completely. > >Of course outdated programs do not run well on dual AMD. You might find that "outdated" program _very_ difficult to beat, however. That's all that counts... > >> >> >>> >>>you can see the results yourself for amd: >>>http://www.specbench.org/osg/cpu2000/results/res2002q3/cpu2000-20020812-01551.html >>> >>>for intel: >>>http://www.specbench.org/osg/cpu2000/results/res2002q3/cpu2000-20020909-01639.html >>> >>>This is the *official* specbench mark. both manufacturers did their best >>>to produce optimal versions of each product. Intel even uses its own >>>compiler. Without this buggy compiler (for DIEP it is buggy, i do >>>not know for others; it gets a lot of nps that compiler at intel >>>processors but not giving correct evaluations and it is NOT a bug >>>in diep, i found out in compiler what is the problem as posted >>>before) they would be again hell slower. >>> >>>I am not sure whether Bob has verified whether that compile from intel >>>is a bugfree compile; whether it plays as good when using big hashtables >>>like a default compile of visual c++ or even latest gcc version. >> >> >>I have to provide them with several test sets that must match my node counts >>_exactly_ for them to "validate" their executable. Therefore there is little >>doubt that their compiler is working fine. I only use the Intel compiler now >>and it works perfectly. >> >> >> >>> >>>Getting a zillion nodes a second doesn't say much about all nodes being >>>non-random :) >>> >>>So reality is that the above result in reality is even more positive for >>>AMD than it looks like. We simply cannot trust these intel c++ compiles. >> >>Sure you can. I have tested the 6.0 release of their compiler exhaustively, >>comparing various optimizations with a known good executable from gcc 2.95.2, >>and the intel compiler is producing perfect code from a comparison of the >>two... >> >>> >>>Best regards, >>>Vincent
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.