Author: Robert Hyatt
Date: 07:29:42 11/07/98
Go up one level in this thread
On November 07, 1998 at 10:06:00, Robert Hyatt wrote: >On November 07, 1998 at 01:35:04, Roberto Waldteufel wrote: > >> >>On November 07, 1998 at 00:16:24, Robert Hyatt wrote: >> >>>On November 06, 1998 at 17:08:38, Tom Kerrigan wrote: >>> >>>>Depends on the program. My guess is that many programs will run much faster on >>>>the o/c Celery because of its faster L1 cache. Many other programs will run much >>>>slower because of the smaller size of the L1 cache. >>>> >>>>As for the hash table, the village idiot can tell you that a 128 MB hash table >>>>can not fit in 128 k of L1 cache. Hash table size is a total non-issue, unless >>>>you use a hash table that's really really really small and it DOES fit in L1 >>>>cache, in which case it's pretty much useless anyway. >>>> >>>>-Tom >>> >>>A couple of things.. I assume you meant L2 but typed L1? IE the celeron L1 >>>is the same as the PII L1 size and speed-wise. L2 is another matter, with >>>the PII having 512K at clock/2, while the celeronA has 128K at clock/1... >>> >>>But as far as hash tables go, they don't count for cache... the average program >>>executes 2,000 instructions (or more) per node, which means only a couple of >>>those instructions access the hash table, the rest do other things... small >>>enough that hashing has little to do with cache efficiency...IMO... >>> >> >> >>Yes, but don't forget that PII has its cache divided equally between code and >>data usage, so if the other 1998 instructions do not access large amounts of >>memory, many of the hash addresses may remain in data cache long enough to get >>used, since the instructions themselves are fetched in blocks from (hopefully!) >>the code cache, independantly from whatever is goning on with the data cache. >>Trouble is, I can't think of any way to actually test this, since you can't turn >>cache on and off at will. >> I forgot to add that I think you have confused the cache concept. On all the pentiums, from day 1, the L1 cache was broken in half, 1/2 for data, 1/2 for instructions. The original Pentium had 8K for each, the newer PII has 16K for each. However, the L2 cache is "unified" which means data and instructions are mixed in it with no distinction. This is done because the L2 is "off-chip" and it is complicated to let an external cache know whether the cpu is fetching data or an instruction. Also the L2 cache uses a basic direct-mapping design as opposed to the set-associative L1 cache... > > >I still maintain that cache and hash don't fit in the same sentence. THe >whole idea is to produce signatures that vary wildly from move to move to >uniformly (hopefully) distribute the hash probes over the entire hash table. >If you do that well, you have practically *zero* chances of getting hash hits >from the cache... > > > >>Another point about comparing the Celeron and the Pentium is pipelining. I don't >>know how it works with the Celeron, but on the PII you can effectively process >>two instructions at once *if* the code is optimised properly, and the degree to >>which this is done may have a big effect on how fast the same piece of code runs >>on the two boxes. So I would think that with a program optimised for Pentium, >>the Celeron might be slower, whereas for another program not optimised for >>Pentium, Celeron might be faster (I believe that Rebel is much faster on >>Celeron). In marked contrast to the plain Pentium and Pentium MMX, the PII and >>PPro can automatically reorder the instructions within a single instruction >>fetch block to optimise pipelining, making the execution of non-optimised code >>much faster, but there are still advantages to be had in terms of execution >>speed with instruction ordering in order to maximise the efficiency of the >>instruction block fetching process, which is not automatically optimised at run >>time like the pipelining is. > > >that's not actually true on the P6/PII/celeron... they all use the "instruction >pool" concept where a *bunch* of instructions are fetched (up to 64 IIRC) and >kept in a "pool"... there the processor can do out-of-order execution, rename >registers where you have load-xx-yy-zz-store using a register, so that it can >find even more parallelism... IE the whole concept of the P6/PII architecture >was to ease the optimization requirements on the compiler... and, in fact, I >can compile for a 486 and not slow my code down a lot on these machines, >because there is no "pairing" requirement by the optimizer since the hardware >can look so far ahead to do its own "pairing" for the super-scalar pipes... > > > > >> >>A big plus for PII and Pro machines (not older Pentiums) is the very vast bit >>scan instructions. I have no idea how well or badly the Celeron compares here, >>but these instructions are extremely useful for bitboard operations, so in the >>context of chess programming this is an important issue, although for most other >>applications it is probably irrelavent. >> > > >celeron is *identical* to the PII... the *only* difference is the cache... it >is smaller (128K vs 512K) but faster (runs at core cpu speed rather than >cpu/2 speed like the PII) > > > >>Best wishes, >>Roberto >> >>> >>> >>> >>>> >>>> >>>>On November 06, 1998 at 11:58:19, Ren Wu wrote: >>>> >>>>>Hi, all >>>>> >>>>>Sorry if this is a little offtopic. >>>>> >>>>>I was almost ready to get a PII450 system, until i found that everyone seems be >>>>>able to overclocking Celeron 300A to 450 as well. The huge price difference make >>>>>me think twice on this. >>>>> >>>>>Did anyone here has a Celeron 300A, and o/c to 450? If so, what is the >>>>>performance difference compare with the real 450? Will be nice if someone can >>>>>post some data, like crafty's benchmarks, although Norton SI is also good. >>>>> >>>>>Celeron300 A only have 128K L2, is this a big disadvantage even o/c to 450, when >>>>>you have a huge hashtables (say 128 or 256MB)? >>>>> >>>>>Thanks, >>>>> >>>>>Ren.
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.