Author: Dan Newman
Date: 22:17:48 09/27/00
Go up one level in this thread
On September 27, 2000 at 19:47:09, Vincent Diepeveen wrote: >On September 27, 2000 at 19:29:53, Eugene Nalimov wrote: > >>RDRAM-to-CPU latency is not 4 times faster when you are randomly access memory. >>Actually, it easily can be *higher* than for SDRAM-100. >> >>RDRAM shines when you are moving a lot of data around using sequental memory >>access -- i.e. memcpy() kilobytes of memory. I doubt you often do that in Diep. > >I am quoting RDRAM-to-CPU latency from the tables as shown, >which is higher as SDRAM, >HOWEVER RDRAM runs at faster speeds as SDRAM ever will run >(ddr ram is really the maximum one will ever be able to get out >of SDRAM technique, after that we'll only see similar developments as >RDRAM), so the number of clocks delay for a random lookup should be >what i wrote in the example, unless the person making the article >didn't very accurate make the article. > >So where the latency of fast SDRAM is 10T, for RDRAM it's 15T, >yet RDRAM runs at 1.25ns, and SDRAM 133Mhz at 7.5ns, so that's where >the big win for RDRAM is. > >I multiplied the 2 with each other and came down to my relative >calculations that SDRAM getting a single memory line is 4 times slower >as RDRAM. > >There are very CONFUSING pieces of information with regard to >RDRAM versus SDRAM, that's the one thing i'm 100% sure of, if anyone >reading this has RDRAM to his avail i'll be happy to deliver a free >copy of diep to him/her if this person is the first to test the speed >of diep at RDRAM. > >>For technical deyails you can take a look at >> http://www.realworldtech.com/page.cfm?ArticleID=RWT110799000000 >> http://www.realworldtech.com/page.cfm?ArticleID=RWT112299000000 >> http://www6.tomshardware.com/mainboard/00q1/000315/index.html > >Yeah i read those too, not exactly what i want to know. Most >interesting for chessprograms are getting at a random place in >memory a byte or 32 to 128 at most. > >>Eugene >>On September 27, 2000 at 18:46:57, Vincent Diepeveen wrote: >>>On September 27, 2000 at 16:22:52, Dan Andersson wrote: >>>>Do you have any benchmarks supporting your view? I'm just asking as I don't have >>>>any. A benchmark simulating random accesses of small fragments of memory should >>>>do it. The architectural design choices taken when designing RDRAM seems to go >>>>against what you say. Namely, its time expensive to select a new memory location >>>>to read from. A chess program would need to read a fair amount of data from >>>>memory to mortgage that. But then again every programs mileage may vary. RDRAM >>>>is hot coupled to streaming data and SIMD instructions. >>>> >>>>Regards Dan Andersson >>> >>>when i took my draughtsprogram from EDO ram to SDRAM it was hell faster >>>suddenly. Now i heart RDRAM is slow. So i looked up latency. >>> >>>Latency is 4 times faster, not because the latency itself is faster, but >>>because latency times speed at which the RAM runs is so little compared >>>to SDRAM 133Mhz. >>> >>>So practically there is simply no discussion. This runs a lot faster. >>> >>>Yet when we talk about *how much does it speed me up*, then we really >>>get to an interesting question as i don't know! >>> >>>i didn't test it yet at all, i was just amazed that this new technology >>>is cracked down to the bottom in all kind of articles where it's obviously >>>a lot faster for me as *any* sdram, whether it's DDR or not! >>> >>>Yet not everything fits in 256kb L2 cache for sure, so it's not only >>>the hashtable lookups that are profitting bigtime from it, also the many >>>evaluation tables and all kind of tables used to lookup things are profitting >>>from it. >>> >>>The huge profit is basically caused by the huge slowness of a lookup >>>at the current SDRAM. >>> >>>In my dual PIII800 slot1 there is no 133Mhz SDRAM. My supermicro motherbord >>>doesn't even support it! >>> >>>i have 100Mhz SDRAM. >>> >>>That's another 33% slower *at least* as 133Mhz. >>> >>>So a single lookup in memory is in its most realistic case: >>> 10ns x 11T = 110 clocks. >>> >>>You can do a lot in 110 clocks! >>> >>>If that gets suddenly down to less as 20 clocks, then >>>it's clear that this rocks bigtime. >>> >>>considering the huge number of tables in my program which all together >>>eat hundreds of kilobytes of RAM, i'm estimating that speedup *might* >>>be like 20% or so in the middlegame for DIEP. >>> >>>However programs that are very fast and are basically wasting their system >>>time at hashtables might profit even more. I wouldn't be amazed by a 2 fold >>>speedup for certain programs. >>> >>>That's what EDO ram to SDRAM did for my draughtsprogram at least... I actually tried an RDRAM machine recently. I ran my chess program benchmark (WAC at 1s/posn) on a P3/933 + PC800 and got 1060 knps. I have a P3/933 with SDRAM at home. On that system I get 1083 knps. So, at least with my program, SDRAM is slightly better. I suspect that SDRAM will actually be a whole lot better if your program is at all memory speed bound. Mine isn't apparently: when I set the memory to run at 100 MHz instead of 133 MHz (which I can do independent of the FSB speed with the motherboard I'm using) I get 1066 knps--which is still faster than the RDRAM result... -Dan.
This page took 0.01 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.