Slashdot Mirror
Rambus Takes Another Shot At High-End Memory
An anonymous reader writes "Tom's Hardware is running an article about Extreme Data Rate memory (XDR DRAM for short), which was developed by Rambus and now entered mass production in Samsung's fabs. Right now, Rambus says the memory is only for high-bandwidth multimedia applications such as Sony's Cell processor, but the company ultimately hopes to push XDR into PCs and graphics cards by 2006. Time will tell if Rambus has learned from the mistakes it made with RDRAM a few years ago."
8GB/sec is good but not if the latency is higher than DDR.
People seem to forget that the "Random" part of RAM is kinda crucial.
Tom
Someday, I'll have a real sig.
I have adamantly refused to purchase any system that would use their memory for years, and more to the point have made that decision for others that depend on me making that decision. That's a lot of computers over the years were talking about. I am also far from alone.
But doesn't standardization decrease profits? Over the long term, that wouldn't allow for companies to force customers into buying their upgrades. Or is there some sort of deep economic thinking behind what MBCook has said that I don't understand? After all, I'm not an economist.
Personally, I prefer to blame the incomprehensible Michael Spindler, CEO of Red Ink Corps.
Will it have no penalties if the R really mean Random? Or we beter change Dynamic Random to Demi Random? You know, peak bandwidth is great, but the real world is a bit about real uses, different apps at the same time, jumping around, not forcing you into something that seems to be a tape or a disk, CPUs already wait too much. Current RAM already has issues, RDRAM had a lot more and failed (price, signal noise and legal tricks were the other legs of the "winning" tactic). The article doesn't have the word latency at all, just how "great" it is going to be.
That would be an unusual special case. First off, most (non realtime) 3D rendering isn't terribly bandwidth or latency sensitive. Assuming the CPU is fast enough that it isn't the main bottleneck, such apps will tend to be more sensitive to latency than to bandwidth. When tracing a ray, for example, one may need to access data from all over memory to do hit-testing, but not need very much information in total. So, the relatively poor latency characteristics of RDRAM don't really suggest a keen funtansticness for 3D rendering. And, considering that current single channel DDR400 has as much bandwidth as dual channel RDRAM did... Well, I'm just surprised that your app would have such a benefit. I'd suspect that there were other differences that caused such a difference in your benchmarks. Do you have any more specifc information, such as what app you use, what sort of scene it was, and what the test systems were?
If you were dealing with slightly different steppings of the same CPU (I assume a P4?) it would be possible that you had two CPU's of the same clock speed, but the newer stepping was less efficient per clock. The P4's, over time, have been tweaked to be less and less efficient over time, in order to facilitate higher clock speeds. RDRAM was popular with the very first generation of P4's, so it'd be logical that the benchmark you saw may have been a newer core. That shouldn't explain a 20% speed difference, but it's an example of a small thing that may have contributed to making the memory system appear to be the determinant item in performance.
On the other hand, I can buy quality 1GB DIMMs for $250. Divide by 4 (rough guess. SRAM at 6T should be 6x the price, but DIMMs have caps too. 4x the manufacturing costs seems reasonable, assuming the infrastructure were in place), and you've got 256M SRAM modules for $250. Obviously that's a bit on the spendy side for large capacity RAM, but clearly there's a market for faster DIMMs. Unfortunately, DRAM access time, at about 5ns, isn't the major component of memory latency, which even on the best systems runs 10x that. The market won't bear 4x the price for a 10% increase in speed.
This means that for SRAM to be useful, it has to be paired with a lower-latency interconnect. Some apps would benefit tremendously from 128M of what would amount to an L3 cache, even to the point that the $400 or so extra it would cost might be worth it. It's clear however that the market doesn't consider that a worthwhile expenditure.
Although newer system architectures such as AMD's Opteron platform are moving to more closely-attached RAM, the engineering and manufacturing challenges involved in attaching memory as tightly as it is to a GPU have so far proven more expensive than the payoffs warrant. With improvements in manufacturing and interconnect technology, I'm sure we'll see ever-tighter CPU-memory integration. I doubt however the technology will move to SRAM or an SRAM-equivalent simply because the performance/heat trade-off isn't favorable. Saving a few ns of latency on the memory chips is peanuts compared to the 10s of ns of latency in the connection to the CPU, which is probably a much more tractable problem.
High-speed Road Trip (18.000KPH)
Wasn't Rambus run out of PCs due to their crooked practices anyway? What makes them think people won't forget? Didn't think I was going to hear that name again. (shakes head in grief)
Also, many of these applications are well suited to streaming data in and out of memory. RDRAM was / is known for high sustained data throughput but less than stellar random access. That makes it well suited for video memory but less than optimal for main system memory on processors unless the processor is designed to burst blocks of memory in and out of cache.
RAMBUS can go shit all over themselves.
What about smaller capacity DIMMS, but more of them, with clever hardware that chopped up memory access across smaller memory blocks, you know, like some sort of "RAID for DRAM"? I guess I remember stuff like this in Tannenbaum, etc. from the early 90's. Memory Interleave, I guess. Old mainframe tricks.
We have 4-way associative cache and all sorts of other ways that try to work around memory latency to speed up cache, why not try to do similar tricks with DRAMs?
Or, instead of a 64-bit wide memory bus, what about 32 read and 32 write serial "buses", with perhaps a 16 or 32-bit controller bus, all on the DIMM, with some clever trickery to turn a 64-bit wide memory read into an 8-channel serial read, with really fast buffers in the memory controller?
I imagine that RAMBUS has kind of the right idea (i.e., high speed serial bus, ala USB, ala 1394, etc), but they burned their bridges, right?
Hmm... I just don't know.
Maybe the consoles, but those are usually sold at a loss to get people to buy games. When it comes to HDTV... I don't know about you, but I don't see someone shelling out $7,000 as being price sensitive when a larger screen DLP projection TV goes for thousands less.
And one of the applications they were talking about was high-end video cards. A high end consumer video card costs more than a 250gb SATA hard drive, but you can drop 2 or 3 generations back, have more than enough power to play all but the most bleeding edge games for the next year, and save $200. But there's a not-inconsequetial market that will pay the $200 premium to eke out a 10-15% gain in FPS.
A Kia costs like 1/4 the price of an *entry level* Mercedes, but you don't see everyone driving Kias. There's a decent-sized market that pays the premium for performance, for bragging rights, etc. This is the market they seem to be going after. - Greg
Start a happiness pandemic
As someone else already said, "people seem to forget what the R in RAM stands for".
What kills RAM nowadays in common scenarios is latency. Whenever there's a cache miss, or a mis-prediction makes you flush the CPU's pipeline and start again, what causes the CPU to stall is latency. You get to wait until that request is processed by the RAM controller, is actually delivered by the RAM, makes its way back through the RAM controller, and only then you can finally resume computing. That's latency, in a nutshell.
And it's already _the_ problem, and it's gotten steadily worse. A modern CPU has to wait as many cycles for a word from RAM as an ancient 8086 would have if you ran it with a HDD instead of RAM. It's _that_ bad.
That's why everyone is putting a ton of cache and/or inventing work-arounds like HyperThreading. And even those only work so far.
And again, it's only going worse. DDR did increase bandwidth, but did buggerall for latency. Your average computer may well yet transfer two words per clock cycle with DDR, but still has 3 cycles CAS latency like SDR had. And DDR 2 has made it even worse.
So FBDIMM's great big advantage is that it lets you have _more_ latency? Well, gee. That's as much of a solution as a kick in the head as a cure for headache.
As I've said, "no, thanks." If Intel wants to go into fantasy land and add yet another abstraction layer just for the sake of extra latency, I'm starting to think Intel has plain old lost its marbles.
A polar bear is a cartesian bear after a coordinate transform.