Author: Vincent Diepeveen
Date: 16:47:09 09/27/00
Go up one level in this thread
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...
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.