Author: Vincent Diepeveen
Date: 11:28:23 12/04/02
Go up one level in this thread
On December 04, 2002 at 13:55:47, Jeremiah Penery wrote: >On December 04, 2002 at 13:32:01, Vincent Diepeveen wrote: > >>On December 04, 2002 at 11:42:17, Matt Taylor wrote: >> >>>On December 04, 2002 at 10:43:59, Vincent Diepeveen wrote: >>> >>>>On December 04, 2002 at 10:21:08, James T. Walker wrote: >>>> >>>>>On December 04, 2002 at 08:00:35, martin fierz wrote: >>>>> >>>>>>hi, >>>>>> >>>>>>i'm on the lookout for a new PC for endgame database computations. i'll probably >>>>>>be buying a lot of ram, 2-3GB. i see that there is a big price difference >>>>>>between DDRAM and SDRAM. IIRC the main difference is that you get a larger >>>>>>bandwidth, but about the same latency with DDR - so i suppose i'm better off >>>>>>buying SDRAM for my application. any opinions of the experts? >>>>>> >>>>>>thanks in advance >>>>>> martin >>>>> >>>>>For what it's worth: I purchased one stick (256M) of DDR ram to compare to my >>>>>cheap SDRAM. I found no noticable difference in chess performance (just price). >>>>> I did not do any extensive testing. I simply compared Fritz marks. I suspect >>>>>that in the future most motherboards will not accept the SDRAM. >>>>>Jim >>>> >>>>I see a big difference. 64 versus 32 bytes cache lines matters >>>>a lot for DIEP and all software that doesn't fit within L1 cache. >>>> >>>>Best regards, >>>>Vincent >>> >>>Cache line size is a part of the CPU, not the ram. There are a number of >>>transitional products, both P4 and Athlon, that accept both SDRAM and DDR SDRAM. >>>(However, I have never heard of anyone happy with these products.) >> >>the P4 ended up being a lot faster for DIEP when i tested a p4 with ddr ram >>isntead of RDRAM. >> >>P4 with ddr ram (northwood) is like 1.5 : 1 for a K7 >>used to be 1.7 : 1 to a k7 with rdram. >> >>So 1.7 Ghz P4 rdram == 1.0Ghz K7 for DIEP >> 2.4 Ghz P4 ddr == 1.6Ghz K7 for DIEP (both ddr). >> >>DDR is a big step forward!! >> >>i don't know where the processor gets 64 bytes instead of 32 bytes in >>the design. I just know it gets 64 bytes, versus SDRAM 32. > >Hash probes in a chess program depend on latency, not bandwidth. RDRAM sucks >for latency, where it is at least double that of SD/DDRAM. >For the tablebase creation, I would expect this to depend much more on streaming >bandwidth - there, RDRAM will win. Not at all. Practical bandwidth from DDR ram is better. But besides from that in my own generator i can put an entire 6 men bitmap in RAM (one side to move win or loss in N moves to conversion). That means that latency there is the only important thing. Harddisk speed is simply irrelevant compared to RAM latency. You can get next buffer from positions sequential from harddisk which is about with 160MB/s that's like 1 billion positions. getting the like 20 equivalent moves from that from RAM is the major problem. Of course skipping already the ones that are already known to be either winning or losing (depending upon what pass you are at). All those lookups are in RAM therefore. harddisk speed is irrelevant. Is anyway irrelevant knowing how much ram nowadays systems have. A single 6 men with pawns buffer is like 18G entries. To give example from my own simple generator (i do not use the extra optimizations nalimov uses, because it slows down the indexing function too much as i want to generate all 6 men within a year instead of many years; cpu speed is the limiting factor): 159 kbnkbp 00240041 18141551280 So that's for kbn kbp in my generator 18.1G entries. So looping sequential through the positions in small buffers, you can easily see that i can do random lookups to memory easily as this is just a bitmap of: 2267693910 bytes. That's very luckily smaller than 3 GB because windows doesn't allow more memory space than 3 GB if i am correct for my K7 computer and x86 in general. So a U160 SCSI disk and a machine that's just generating can generate all 6 men within a year. Of course i do not save the mate in 'n' positions. So when combining the bitmaps i just keep left with the 'win/loss bitmaps and create win/draw/loss from it instead of mate in n or loss in n, which nalimov saves. Then i compress it all. Uncompressed i have : In total 510 egtbs using 2631231208124 entries That's for 1 side to move. For both sides to move, just double it. So say 5.22 Tera entry. that's uncompressed 5.22 / 5 positions a byte = 1.044 Terabyte to store. That compressed will go to i suppose around 150GB. Perhaps i can get it smaller. Still toying with Andrew Kadatch superb compression there. All 5 men fit at 1 CDrom.
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.