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."

Comments

Is the Price worth It?

[RicJohnson]

Look- it's simple - What is the Price vs. Performance?
That is why I now ignore the MHZ and made the switch to AMD.
Name brand inside is not worth the extra 20%
I am sorry - I will never trust RamBus again, after I spent an extra $1200 on memory a few years ago and my computer ran WORSE.

It will be awhile

[I_am_Rambi]

before AMD might even thinking about accepting it. Since AMD now puts the memory controller on chip, AMD will have to see proff that it is faster. AMD will not go for DDR until it gets faster. Their reasoning, DDR2 adds cost and decreases performance. Without help from AMD, Rambus might be heading down the same track.

Re:It will be awhile

[geekoid]

so, are you talking about AMD? I wasn't clear...

Re:It will be awhile

[MBCook]

All the more reason to move to FBDIMMs. AMD would put one memory controller on their chips, and it would work with SD, DDR, DDR2, Rambus, XDR, or anything else someone wants to put on. Makes things easy. Becuase the physical interface is constant and buffered, you don't get the problems of needing a different socket for every kind of RAM out there.

Unfortunatly, no one seems to be pushing for this despite the headaches it would remove. All you'd have to do is make your memory controller able to recieve faster (like going from DDR333 to DDR400). Plus, with the memory not directly connected, memory makers would not only compete evenly (since the user wouldn't need to know the difference between DDR2 and XDR except speed and price), but they could add other things like an extra cache level in front of the memory just by replacing RAM. And it would mean that the computer you bought today would take the memory that was available 3 years from now. Right now SDRAM costs a FORTUNE. But if you had a computer that takes FBDIMMs, instead of paying $50 a stick for 256mb sticks, you could buy at the price of DDR today (say 512mb for $25 or whatever it is today).

Just think, you wouldn't need to buy new types of RAM for your PC every 2 years.

Re:It will be awhile

[MBCook]

One other thing I forgot. With FBDIMMs it would be easy to replace your DRAM with SRAM (if prices dropped enough) because the refresh circuitry is on DIMM. That means one less thing that the memory controller has to do, which means less complexity and less silicon (not that the refresh logic takes up a huge ammount, but every little bit). When magnetic RAM comes along, you wouldn't need yet another memory controller.

And (since I think it's serial, instead of parallel like current RAM) it would SERIOUSLY decrease the pincounts of the Opteron and northbridges. Think if you could have quad channel memory in your desktop as an option. Right now the CPU would need THOUSANDS of pins to do that. But you might be able to do it with the current 939 pins on an Opteron if you used FBDIMMs.

Ah, dreams.

Re:It will be awhile

[funkywhat2]

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.

Re:It will be awhile

[Anonymous Coward]

Uh, you realize that with FBDIMMs, there is an unavoidable latency for serializing/deserializing between the memory controller and the DIMM? And that as cache lines get longer (Pentium M has 64-byte lines, PPC970 has 128-byte lines) the serialization will increase the pressure per FBDIMM lane. Then, in the effort to reduce the lane blocking for transferring large cache line reloads, they'll want to increase the lane frequency even more, which means you're going to have to end up getting rid of your FBDIMM for FBDIMM-2.

Besides, it's in the interests of the memory makers to make you throw away your old memory so that they can sell you new memory.

IMHO, FBDIMM is just Intel's hedge against RAMBUS going bust. The point of RAMBUS was to reduce pincount per chip by reducing the width of the channel between the memory controller and the chip, and to decouple the notion of a memory controller controlling specific banks of memory. FBDIMMs are to solve the same problem, except RAMBUS is shipping already.

Re:It will be awhile

[flynns]

Just think, you wouldn't need to buy new types of RAM for your PC every 2 years.

...Thus, exactly why it won't happen.

Re:It will be awhile

[joib]

IMHO, FBDIMM is just Intel's hedge against RAMBUS going bust. The point of RAMBUS was to reduce pincount per chip by reducing the width of the channel between the memory controller and the chip, and to decouple the notion of a memory controller controlling specific banks of memory. FBDIMMs are to solve the same problem, except RAMBUS is shipping already.


Reducing pincount is one important reason for FB-DIMM, but the real reason for it is to get out of the capacity/speed tradeoff game. See, many systems need lots of memory. However, with current DDR-400 or DDR2-667 you can only put two devices per channel. If you want more RAM than what fits in two devices, you have to reduce the speed. FB-DIMM gets around this problem by using point-to-point links between the devices.

Yes, this increases latency a little bit, but there really isn't any other practical way to increase speed without reducing capacity. However, FB-DIMM compensates for the increased latency by allowing many outstanding transactions on each channel; because of this, latency under high load is actually supposed to be lower than for traditional RAM tech with the same specs.

Re:It will be awhile

[Moraelin]

One reason the AMD 64 works so well is precisely because they _reduced_ latency. That's basically the great advantage that the IMC (Integrated Memory Controller) offers.

Funny abstraction layers and everything being agnostic of everything else is a nice CS theoretician fantasy. In a CS theory utopia everything should be abstracted, or better yet virtualized. Any actual hardware or other implementation details should be buried 6 ft deep, under layers after layers of abstraction or better yet emulation.

The problem is that reality doesn't work that way. Every such abstraction layer, such as buffering and translating some generic RAM interface costs time. Every single detail you play agnostic about, runs you the risk of doing something extremely stupid and slow. (E.g., from another domain: I've seen entirely too many program implementations that, in the quest to abstract and ignore the database, end up with a flurry of connections just to save one stupid record.) Performance problems here we come.

The AMD 64 runs fast precisely because it has one _less_ level of abstraction and virtualization. Precisely because their CPU does _not_ play agnostic and let the north-bridge handle the actual RAM details. No, they know all about RAM, and they use it better that way.

So adding an abstraction layer right back (even if one that moves the north-bridge on the RAM stick) would solve... what? Shave some 10% out of the performance? No, thanks.

Or you mention SRAM. Well, the only advantage to SRAM is that it's faster than DRAM. Adding an extra couple of cycles of latency to it would be just a bloody stupid way to get DRAM performance out of expensive SRAM. Over-priced under-performing solutions, here we come.

Wouldn't it be easier to just stick to DRAM _without_ extra abstraction layers to start with? You know, instead of then having to pay a mint for SRAM just to get back to where you started?

Not meant as a flame. Just a quick reflection on how the real world is that-a-way, and utopias with a dozen abstraction layers are in the exact opposite direction.

Re:It will be awhile

[hattig]

This really isn't memory for mainstream computers, it is more for consoles and devices which don't use DIMM slots and the like but directly attach a fixed amount of memory to the board. As such it might also be used on graphics cards, and it might get used on FBDIMMs because they also contain the memory controller.

Still, if the technology is decent for the price, then I don't see what anyone would have against it at a technological level.

Re:It will be awhile

[hawk]

I'm an economicst, maybe I can help.

Commodification of a product reduces profit to "normal" returns. Economic profit and accounting aren't the same; "normal" accounting profits are "zero" economic profit.

Being the first out with something yields a short-term economic profit. As it becomes a commodity, profits drop to normal rates.

Look at memory prices--the first one out with a new sized gets to charge a high price, wich drops as others leap in.

hawk

Re:It will be awhile

[rewt66]

939 pins???!!!???

Wow. I had no idea. I'm kind of an old guy, but I'm used to CPUs having address and data pins, and some power and ground pins, and a very few bus control signals, and that's basically it. Well, clearly that's not the case here, even if they used a 512-bit-wide data bus, which I kind of doubt that they did (though it would be a great way to increase bandwidth).

In fact, about 10 years ago I decided that the hot future CPUs would have bandwidth issues (right on the money), and that the way to solve this was with a high pin count and an enormously wide (512- or 1024-bit), non-byte-addressable data bus. (Non-byte addressible cuts down on the bus-control craziness, which can help on the speed front.)

Is Intel actually doing this? If not, what in the world are they doing with all those pins?

Re:It will be awhile

[Kent Recal]

If not, what in the world are they doing with all those pins?

DRM.

Re:It will be awhile

[OwnedByTwoCats]

Standardization will make it easier for competitors to offer compatible product. Which could reduce profit.

But standardization also increases the size of the market, which can increase profit. It also reduces risks.

Are you holding off buying an HD DVD player to see whether Blu-Ray or HD-DVD wins? Standarization would reduce the risk to the consumer, and to the producer, that they'll invest in the unpopular choice.

So, on the whole, standardization is frequently viewed as a good thing.

Why do we use DRAM in this day and age?

[Dancin_Santa]

SRAM is much faster, closer to the core of the CPU, and plentiful (if the chip manufacturers wanted it to be).

Who needs a gig of RAM when you can have a gig of cache?

If they need swap space, they can always write back out directly to a disk-based swap file.

Re:Why do we use DRAM in this day and age?

[Anonymous Coward]

cuz it's 6-9x more transistors per bit so your gig o sram costs at least 6-9x more than your gig o sdram.

Re:Why do we use DRAM in this day and age?

[tomstdenis]

...SRAM is much more expensive to produce? It also takes more power and generates more heat.

That and the benefits of cache go DOWN as the size of the cache goes up. Past a MB or two the benefits would be lowered. Also as the # of address lines goes up the access gets slower. And finally a bigger bottle neck is that "external memory" is external.

So unless you want to pay for a cpu with a GB of onboard "memory" in the form of SRAM.... the benefits won't be that high.

Tom

Re:Why do we use DRAM in this day and age?

[be-fan]

Because SRAM takes up 6 transistors per bit, while DRAM takes up 1 transistor per bit. The biggest mainstream CPUs run about ~150m transistors, and that's only enough (if everything were cache), about 3MB.

Re:Why do we use DRAM in this day and age?

[lachlan76]

Because SRAM designed to run at full chip speed is Fucking Expensive(tm).

Why do you think there is only a MB or two at the most?

Re:Why do we use DRAM in this day and age?

[Stevyn]

Interesting?

This is like saying why paint your walls with off-white stuff when you can coat them in a layer of gold that resists tarnish?

Well, for one thing, it's greatly more expensive.

Re:Why do we use DRAM in this day and age?

[Anonymous Coward]

Why couldn't we expect something like that with SRAM?

cuz the expected DRAM bits/chip (1-2Gbit/chip, i.e. 128MB per chip) are now to the point where SRAM chips of the same capacity are not economically feasible to make.

Think floppy disk versus CD-R... They can extend the capacity of plastic magnetic media a lot, but when a more cost-efficient medium becomes available, there's no economically profitable reason to do so.

Re:Why do we use DRAM in this day and age?

[Anonymous Coward]

SRAM is not a limited resource. The analogy is not correct.

As demand for gold increases, the cost of gold rises because of the scarcity of the element. However, for SRAM, the production of it can be ramped up to whatever level is necessary to meet demand.

Higher efficiency in the manufacturing of SRAM would lead to lower prices (though not necessarily lower than the current chip prices).

Re:Why do we use DRAM in this day and age?

[Jeff DeMaagd]

That post still reflects a lack of understanding in the technology.

For a given area of silicon, you could have 1 gigabit of DRAM or 128 Megabit of SRAM. Is it worth that trade-off? One can make more chips, but making chips uses a lot of expensive and toxic chemicals, and fab time isn't free either.

Re:Why do we use DRAM in this day and age?

[nmosfet]

If one were to make a memory chip out of a die with a certain set size, they will always be able to make a DRAM chip with a much greater capacity than a SRAM chip assuming the cost of production (including the equipment costs) is held constant. That is why DRAM chips are used.

Re:Why do we use DRAM in this day and age?

[ottffssent]

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.

Re:Why do we use DRAM in this day and age?

[Breakfast Pants]

The size they take up isn't the only concern. SRAM puts off MUCH more heat.

Re:Why do we use DRAM in this day and age?

[dgatwood]

Except it's more like floppy vs. CD-R would be if the floppy disk could reliably shove data at 256x CD read speed.

And SRAM keeps increasing in density, unlike floppies... just not quickly enough to catch up with DRAM. It isn't by any stretch of the imagination a dead tech. It just isn't (currently) cost-effective for use as main memory at the capacity needed.

Re:Why do we use DRAM in this day and age?

[moonbender]

What, you mean it has an in-built heat spreader? Cool.

Re:Why do we use DRAM in this day and age?

[gravygraphics]

Last I checked (admittedly a few years ago), for the same process node, manufacturers were averaging a 20x difference in density between their DRAM and their performance SRAM lines. You could find denser SRAM's nearing 8x, but they were usually slower than DRAM (low power cell phone applications instead of high performance cache applications).

Re:Why do we use DRAM in this day and age?

[TheRaven64]

That and the benefits of cache go DOWN as the size of the cache goes up. Past a MB or two the benefits would be lowered.

To clarify, they increased benefit from cache decreases as cache size increases. Performance with a large cache is not worse than performance with a small cache, but the law of diminishing returns starts to kick in over a few MB. A computer with 4GB of SRAM running at the same speed as current cache memory (assuming no memory controller bottleneck) and no cache would be faster than one with 4GB of DRAM and a cache. On the later, a cache miss would take a hundred or so clock cycles, on the former every memory access would take around 2 cycles. A computer with 4GB of space in its registers would be even faster.

Of course, at current prices this is not feasible. SRAM prices keep dropping, however, and there may come a point where they have a better price / performance ratio than DRAM (although the price is likely to remain higher).

Re:Why do we use DRAM in this day and age?

[tomstdenis]

"on the former every memory access would take around 2 cycles"

See that's wrong. On the machine with a small cache and large DRAM every cache hit is 2 cycles. Even the 512KB L2's that AMD/Intel use are upwards of 13 cycles to access [or more]. It takes time for the address bits to settle and also the larger the cache the longer it will take for the signal to settle (more distance)

With 4GB of cache EVERY cache hit would be larger [say for conversation] access time of say 30 cycles.

So let's compare access times. Cache hits on the "small cache" platform might be split say 60%/30%/10% [for code]. That means most hits will be 2 cycles or ~13 cycles and some upwards of a 150 cycles or so [average of about 20 cycles].

The 30 cycle "large cache" system will still be slower on average then.

In reality though my averages aren't representative of applications like encoders where tight loops make up the largest parts of the execution time. So let's assume that 85/10/5 is more representative. That's an average access of 8 cycles.

That and the fact that SRAM is expensive is why people don't build systems with only SRAM.

Tom

Re:Why do we use DRAM in this day and age?

[Firehawke]

And heat is the LAST thing we need in the CPU right now with this sort of heat issues on the top end. It's getting harder to keep these things stable as it is-- adding another major heat source right in the CPU would assuredly push past the line of what standard cooling can handle.

Re:Why do we use DRAM in this day and age?

[Lars T.]

While the gold market isn't as bad in that regard as that for diamonds, both scarcity and demand are mostly artificial.

Never mind

[LittleLebowskiUrbanA]

if they plan on charging exorbitant prices for their memory again. I inherited a network full of fairly fast (2ghz) Dell boxes using RAMBUS. Sure is fun spending about $300 for a 512 upgrade. Of course you can only install this crap in pairs so there goes your slots.... Junk.. Rather buy a cheap new box than a memory upgrade using this overpriced crap.

Re:Never mind

[bersl2]

I found that ZipZoomFly has halfway-decent prices for RDRAM. At most, $230 for 2x256M.

Re:Never mind

[jandrese]

Gee, only $230 for 512M of memory on 2 sticks? Your price perception has been warped by Rambus. You can get a very nice 512MB DDR DIMM for a little under $100.

Re:Never mind

[bersl2]

Halfway-decent for RAMBUS memory, that is.

Recently got 2x512MB for $137. Yay Newegg!

Good marketing sense

[gbulmash]

Smart plan not to try to make it main RAM. By going after multimedia applications like HDTV, video games, etc. they're targeting a market historically willing to pay a premium to get the best performance. I'll be really interested to see the graphic cards based on it and how they compare with the alternatives.

Re:Good marketing sense

[hackerjoe]

By going after multimedia applications like HDTV, video games, etc. they're targeting a market historically willing to pay a premium to get the best performance.

Is this really true? I think you're smoking crack... HDTV and game consoles are consumer electronics, which is a market almost entirely driven by price. I don't know about HDTV, but I can't think of any way the popular consoles could be construed as including "premium" parts...

Re:Good marketing sense

[mboverload]

MythTV boxes that transcode HDTV need all the power you can possibly give it.

Re:Good marketing sense

[ziandra]

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.

Re:Good marketing sense

[gbulmash]

HDTV and game consoles are consumer electronics, which is a market almost entirely driven by price.

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

Re:Good marketing sense

[Fulcrum of Evil]

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.

consoles are driven by available games and have a perceived maximum price (probably around $300). They are not, for the most part, sold at a loss. That would be illegal for Sony to do. Also, I saw a nice HDTV LCD for $4k over at best buy last week.

also at extremetech

[Anonymous Coward]

I don't visit Tom's as a matter of principle - it's my feeling that Tom's reviews favor his biggest advertisers, not the best technology. ExtremeTech covers the same topic here: http://www.extremetech.com/article2/0,1558,1188770 ,00.asp

Pathetic attempt at FPing

[tibike77]

Well, looks like they haven't learned much from their old mistakes, but are trying to avoid the consequences... smart move targetting heavy bandwidth apps for now.

In the long run, if they can't significantly drop manufacture prices to (let's say) 150% or even 200% of "regular" (by that date) RAM, the boost in speed a computer with "XDR DRAM" will get compared to (again, let's say) "PC800 RDRAM" will be not significant... and I'll bet (regular) people would rather choose 8 GB of "PC800 RDRAM" over 2 GB of "XDR DRAM" any time of the day.

Bottom line: they're either stuck with "speciality hardware" (like graphic cards or high-end servers) or they have to drop (manufacture) prices rapidly if they want to keep selling.

Re:Pathetic attempt at FPing

[jmrSudbury]

I agree. If the XDR RAM retails at $500 then they drop it by 100% to $0, then I may try it since it is free. If they take this poster's advice and drop manufacture prices to 200% of regular, then they would be paying me the regular price to use it. I would go for that! $500 would pay for most of the other hardware. Even if it the regular price was not that high, I could still upgrade my video or sound card.

Wait for it....

[eobanb]

Apple to rebrand it as "RAM Extreme"

Re:Wait for it....

[karakal]

Yeah, then don't complain and install it yourself. Everyone, who buys a Mac and has some understanding of PCs installs it himself. And this one is pretty offtopic.

Re:Wait for it....

[dakara]

I believe Apple RAM is known as iRam and Sun RAM is known as OpenRam

Re:Pathetic attempt at FPing-Apple Core.

[tibike77]

I have to admit I only saw a *real-life* Apple ONCE in my entire lifetime, and that was about 10 years ago. The rest were pictures on the net.

In my (?defence?), I live in Romania, and I highly doubt there's more than a couple thousands of them within the borders of the country.

latency?

[tomstdenis]

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

Re:latency?

[be-fan]

Not necessarily. It depends on the application. In "streaming" applications (hint: 3D rendering like on a graphics card!) the latency doesn't matter nearly as much as bandwidth.

Re:latency?

[mojotooth]

People seem to forget that the "Random" part of RAM is kinda crucial.

Well by gosh, you're right! I totally forgot about that whole "Random" thing.

Unfortunately when I went to jog my recollection a bit and write a program that writes to "Random" places in memory, I got all manner of interesting screens. Did you know Windows has a "Fuschia Screen of Death?" I didn't.

Re:latency?

[Dr. Spork]

Yeah, using this for graphics cards seems like an obvious and good idea. It makes me wonder why they didn't do this with RDRAM. It's so much easier to get a place on a graphics card: no issues about adding memory sticks, no reason to establish an industry standard before soldering on some chips... Yes, it seems like their new ideas have a much better chance of working. (But we still hate them...)

What I'm impressed with is that they actually kept some engineers through their whole lawsuit period, and apparently competent ones too.

Re:latency?

[Lehk228]

using it for graphics cards would be terrible if it has higher latency, graphics processing requires constant "random" access because rendering a life-like scene requires knowing the state of everything in line of sight, as well as ambient and reflected lighting.

Re:latency?

[rsborg]

Yeah, using this for graphics cards seems like an obvious and good idea. It makes me wonder why they didn't do this with RDRAM.

They did... it's called the PlayStation2. If you look closely, you'll see the main memory is Rambus RAM. Which makes sense, because the PS2 is really more of a graphics engine than a general purpose computer.

Re:latency?

[JollyFinn]

using it for graphics cards would be terrible if it has higher latency, graphics processing requires constant "random" access because rendering a life-like scene requires knowing the state of everything in line of sight, as well as ambient and reflected lighting.

Just like the new Geforce 6200 that utilizes pci-express and streams its textures from main memory ;) There is quite possible to increase latency tolerance and graphics cards happen to be one application that is RELATIVELY latency insensitive in a sence that you can HIDE the latency. I'm not claiming its easy, but I claim that nVidia already does already know how to hide memory latency for Gfx.

Re:latency?

[0123456]

"In "streaming" applications (hint: 3D rendering like on a graphics card!) the latency doesn't matter nearly as much as bandwidth."

That used to be true: graphics cards had fixed functionality and long pipelines, so if you knew that you'd need pixel (51, 96) of a texture two hundred steps down the pipeline you'd just ask the cache to fetch it in plenty of time.

Today, though, as they become more and more programmable, they're starting to see latency problems similar to CPUs. It's hard to predict what data a shader program will need, and when you find out what data it needs, you want it _now_ not 200 clock cycles later.

Re:latency?

[be-fan]

Rough visibility culling (based on line of sight) is done long before the scene hits the graphics card. By the time the scene is in a graphics card, the shaders are going fairly linearly through a series of vertex buffers, making highly localized accesses to a few textures in the process. There are very few ambient lights in most games (8 is a common maximum), so their positions are usually stored as arguments to a pixel shader or as part of the OpenGL state. Either way, they are not randomly accessed from memory, but rather they reside in registers. As for reflected lighting, it is not calculated by chasing a ray randomly through the scene. It is calculated by rendering part of the scene to a texture, then texturing selected reflective objects with it.

GPUs are highly parallel stream processors with pipelines that strech to hundreds of stages. They do not do random-access processing very well.

Re:latency?

[be-fan]

It's fairly easy to predict what texture a shader program will need. Shaders, even fairly complex ones, only draw from a few source textures, and even then, in a highly localized manner. Remember, nearly all textures accessed by a shader still contain data in the spatial domain. A small cache on the GPU should still do a good job of hiding memory latency for the shader.

Re:latency?

[be-fan]

However, how many of those accesses are latency sensitive? Most of the accesses you listed are streaming. For example, consider vertex buffers. The GPU doesn't do random access to vertex buffers. It processes batches of vertices at a time. Even with a small vertex cache, it's easy for a prefetch unit to mask the memory access latency. It just has to make sure that the next batch is available in the cache by the time the GPU finishes the current batch. Also consider something like the framebuffer. Most framebuffer access is writes, which are inherently independent of latency. Beyond that, you have to remember that GPUs have extremely deep pipelines. Literally hundreds of pixels may be in different stages of processing at a given time. It's easy enough for the GPU to issue something like a texture fetch early in the pipeline, so it'll be ready by the time the pixel is ready to be textured.

Rambus seems to forget

[onyxruby]

Rambus seems to forget their attempt to shanghai the entire memory business through fraud a few years ago. Perhaps they should be reminded that the IT community has not. They should sell their IP and disolve themselves to avoid losing their stockholders any more money.

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.

Re:Rambus seems to forget

[GoMissedAtTheMAP]

If memory serves me , Rambus, while not an innocent bystander, was closer to being a victim of the large manufacturers conspiring to put them out of business. I did some quick research and apparently a judge just issued a summary judgement against Hyinx, stating that Hyinx infringed on 4 of Rambus' patents (total of 26 times). I agree that Rambus took advantage of some poor guidelines of JEDEC, but they do not deserve all the bad press. They don't manufacturer the memory, they patented the interface between memory and processor. It seems like most people on here view anything that is 'for profit' as evil, and that song is getting old.

Re:Rambus seems to forget

[mboverload]

Wasn't that a different management team than they have now? I got the impression alot of them were fired or left.

Re:Rambus seems to forget

[nfgaida]

I thought it was their submarine patent trick that was the evil bit there. Making a profit isn't bad, but tricking people into building for a standard you have hidden patents on is.

Assuming they did that.

Re:Rambus seems to forget

[GoMissedAtTheMAP]

That is a tough problem that all companies face on standards setting boards. From what I have read, they didn't disclose key pending patents when they were participating on the board, not were they forced to. If that were the case, companies would be less likely to sit on these boards because of the risk of exposing their IP. I don't think that Rambus did anything any other company would'nt do, and it may even have been of questionable morality. But, as I look into this further, it looks like the manufacturers conspired to put Rambus out of business (I found sites that referenced emails, but I don't know of their validity). Either way, the mindset of /. is that free is good, not free is crap.

Re:Rambus seems to forget

[Anonymous Coward]

Rambus intentionally inserted their alleged IP into JEDEC's SDRAM spec in violation of JEDEC rules. Pulling out of JEDEC at the last minute may possibly have circumvented violation of the letter of their agreement, but they acted in bad faith and intentionally subverted the other members.

Cheating others by abusing their good faith to gain an unfair advantage *is* evil, even if the motive is profit.

Re:Rambus seems to forget

[realdpk]

"They should sell their IP and disolve themselves to avoid losing their stockholders any more money."

All they have is IP. They don't make anything.

If they were to sell their IP, chances are it would end up in some larger mega-IP house, which would ram the stick up even further.

Re:Rambus seems to forget

[i41Overlord]

From what I know, Rambus intentionally pulled a fast one.

First of all, they were on a committee of memory manufacturers whose purpose it was to design the next generation of memory, SDRAM. It was in the manufacturers' best interest to form an open standard that could be produced easily.

The strange thing is that Rambus is not a manufacturer. They are an IP company. I don't know why they were on that committee in the first place. What would be in it for them as an IP company to help produce an *open* standard?

As things turned out, they used the knowledge gained on the committee to modify existing patents that they had. From being on that committee, they saw the direction that the industry was about to go. Using that information, they modified their patents with the intention that the industry's new direction would infringe on their patents. They might have even used their influence on that committee to steer the industry to "run over" patents that Rambus held.

To sum it up, Rambus's involvement on that committee was dubious from the beginning. The only reason it was on that committee was to help position itself for the legal actions that were its ultimate goal.

Re:Rambus seems to forget

[morcheeba]

I'll have to disagree; the parent (as I did too) acted totally professionally. The decision wasn't based on politics (that would require some sort of voting), it was based on the actions of the supplier. I think it was a good choice to avoid suppliers whose business practices you object to. Morals have to start somewhere (and they can't stop because you're working for a company) -- otherwise I'd be recommending stolen goods as the best value for the money.

Incidentally, SDRAM always offered significantly more value.

What about the latency?

[Anonymous Coward]

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.

Re:What about the latency?

[MotiveForce]

I don't have time to try to find a link right now, but I am pretty sure that I've read that XDRAM has much lower latency (than RDRAM.)

I'm in the same category

[Anonymous Coward]

I went out of my way to NOT spec machines with Rambus memory, even when Intel was trying to (ahem) ram it down our throats. The bang for the buck just wasn't there at the time and then Rambus started extorting money from the industry. So that's probably several thousand machines that I either approved or influenced the buying decision for...hopefully, others in our shoes did the same.

Cheers,

The numbers don't lie!

[captaineo]

I was just as mad as everyone else at Rambus' outlaw marketing tactics. But then I discovered, much to my dismay, that even the fastest currently available DDR RAM results in a ~20% speed penalty versus two-year-old RDRAM on the rendering application I use most. I would LOVE to be able to buy more RDRAM, even at a premium price.

Re:The numbers don't lie!

[forkazoo]

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.

Re:The numbers don't lie!

[captaineo]

The test case was intensive ray tracing with Pixar's RenderMan on two systems:

3.06 GHz Pentium 4, 512KB cache, 533MHz FSB, RDRAM
3.00 GHz Pentium 4, 1MB cache, 800MHz FSB, DDR400 RAM

The DDR system is only 86% as fast as the RDRAM system (the RDRAM system is 16% faster). This is despite the DDR system having been purchased almost two years later, and having more cache!

The DDR system does pull ahead for compositing tasks (by quite a bit - in some cases it's twice as fast). I assume this is due to the larger cache.

But ray tracing takes about 90% of my total render times, so it's far more important to optimize. I am disappointed that I can't buy hardware today with the same RAM performance as I got two years ago.

Re:The numbers don't lie!

[Anonymous Coward]

3.06 GHz Pentium 4, 512KB cache, 533MHz FSB, RDRAM
3.00 GHz Pentium 4, 1MB cache, 800MHz FSB, DDR400 RAM

You're probably comparing a Prescott to a Northwood. They're fundamentally different processors -- way more than a remap from 130nm to 90nm, but share enough I guess for Intel to continue branding it Pentium 4. For example, Prescott has longer L1 latency than Northwood, twice as long L2 latency than Northwood, and longer mispredict penalty (11 more stages). All those latencies add up to not-as-good performance at the same frequency.

Re:The numbers don't lie!

[berkut7]

Why don't you use equivalent processors when doing this kind of comparison. Even though the second CPU has 1 MB of cache, it's a Prescott core and can often be slower than the older Northwood at same clock speed because of the much deeper pipeline.

Re:The numbers don't lie!

[RalphBNumbers]

The numbers might not lie, but you do (probably unintentionally in this case).

The test case was intensive ray tracing with Pixar's RenderMan on two systems:

That statement is impossible because Pixar's renderman (prman) is not a ray tracer.
It uses coordinate space transforms and shaders to render, much like a modern 3D video card would (albiet prman only does this after dicing the models to be rendered into millions of quarter-pixel-sized micropolygons, and allows arbitrarily complex shaders of many types).

This mode of rendering obviously has very different memory access requirements than ray-tracing (prman's memory access patterns would probably more like rendering a *really* complex scene via OpenGL or DirectX). Perhaps you can see how this is relavent in refrence to forkazoo's first statement?

If you were actually doing ray-tracing on those two systems, the results might be different...

Re:The numbers don't lie!

[forkazoo]

That would be why I specifically asked for my specific information from the poster. The fact that something was measured doesn't mean it's impossible for the measurement to have a flaw. Also, I didn't say he was wrong, just that it sounded like he was running across a fairly uncommon special case (if my understanding of what he was doing is accurate.) If he is doing something fairly odd, then the fact that it is uncommon wouldn't invalidate his benchmarking, it'd just mean that it may not apply to somebody else.

Re:The numbers don't lie!

[forkazoo]

Traditionally, this was the case, but current versions of prman do support ray tracing. Apparently, they added it around the time exluna was digging into their market share, in order to be competitive. Before that happened, you had to use BMRT as a rayserver for prman. since the guy who wrote BMRT went off to exluna, it obviously wasn't a good marketing move to suggest using his old software to do raytracing with prman, rather than just buying his newer, better software that didn't need prman... :)

Re:The numbers don't lie!

[forkazoo]

Yes, that was exactly the suspicion I had in my post. But, would it actually show a 16% jump in performance. I don't think it should be that big, unless you have a pretty pathological test case. (which the poster may...) Also, I suppose his newer system is only using single channel memory, which would potentially cause some of the performance hit.

Both systems have the same amount of RAM and OS, right? and we are talking about the same version of the software?

Re:The numbers don't lie!

[RalphBNumbers]

Really? Well, I guess I'm behind the times...
Sorry.

Re:The numbers don't lie!

[captaineo]

Aha, that Prescott v. Northwood thing sounds reasonable.

Yes both machines have the same amount of RAM (1GB), same kernel (2.4.28), same software (PRMan 12.0).

I also just got a newer system, 3.2GHz Xeon with DDR RAM. Its performance is virtually identical to the 3.06GHz Pentium 4 with RDRAM. So I guess adding ~150MHz to the clock speed makes up the processor efficiency difference.

Re:The numbers don't lie!

[toddestan]

If I know my Pentium 4's right, the first one is a hyperthreading CPU, and the second one is not. Perhaps that is what is skewing your results so dramatically.

Though, I must say, RDRAM is fast (typing this from a 1.5Ghz P4 with a gig).

RAMBUS on video cards

[orionpi]

They've done this before, SGI used RDRAM on their MGRAS graphics systems. Last time I checked a 3MB TRAM (texture memory upgrade) still goes for about $100. Oh, and the hardware was release 10 years ago.

Re:No thanks to the GPL - [snore....]

[rco3]

It's not so much that trolling is lame (although it generally is), but that this particular troll is OLD, TIRED, and lame. This is like trying to pick the perfect booger. Nobody's ever going to be impressed.

Seriously - don't you have something better to do? Anything?

[yawn]

Re:150million / 6 = 25 million...

[PlusFiveTroll]

150million / 6 = 25 million...

25million bits / 8 = about 3MB.

Parent poster is correct.

Size Matters

[doormat]

1-bit SRAM cell = 6 transistors
1-bit DRAM cell = 1 transistor and a capacitance (not necessarily a physical capacitor, just something that acts like one)

Time Will Tell?

[cacepi]

Time will tell if Rambus has learned from the mistakes it made with RDRAM a few years ago.

Well, Rambus has expanded their latest lawsuit blitz to include DDR2 patent claims, so do you think they've learned?

Re:150million / 6 = 25 million...

[kbranch]

Bits. 150,000,000 / 6 / 8 = 3MB.

Why does RAM suck so much?

[digitalgimpus]

1. Fast RAM is still expensive.

2. RAN changes to quick. I buy RAM for one computer, it's only for that computer. No portability.

I get a hard drive, I can put that in my new system. I get a new mouse, can use that on my new system. Display? Yep. Graphics card? Most likely.

RAM? Not likely.

IMHO they need to standardize RAM like AGP or PCI-X. That way users feel more comfortable investing in it... you can upgrade and keep your RAM.

Re:Why does RAM suck so much?

[rrowv]

> IMHO they need to standardize RAM like AGP or PCI-X.
> That way users feel more comfortable investing in it...
> you can upgrade and keep your RAM.

You may be interested in FB-DIMMs, if they ever come out. Basically a standard (buffered) interface to all RAM you might want to put on there. Just make a new buffer chip and you're set.

Re:Why does RAM suck so much?

[SunFan]

Funny that PCI-X and AGP are on their way out...

Re:Why does RAM suck so much?

[Jeff DeMaagd]

The new memory card standards are there to take advantage of of the latest performing memory.

A problem with your idea is that it is like wanting to keep your CPU but upgrade your computer. You don't want a slow CPU? Why would you want slow memory? Memory you bought two years ago is only going to hobble a brand-new chip.

Re:Why does RAM suck so much?

[Mycroft_VIII]

Actually pci-express is supposed to be on it's way IN. agp is going though.

Mycroft

Re:Why does RAM suck so much?

[Dopefish_1]

Note that PCI-X and PCI-Express are not the same thing.

Re:Why does RAM suck so much?

[Mycroft_VIII]

Maybe not technically, but tell that to marketroids and joe user. I've already seen adds for pci-x and pci-e used interchangeably. Somtimes for essentially the same product on the same website.
In many cases the 'blurb' under each item is just ripped from the marketting. Unless there is a pci-x version of ati's x500 through x800 chipsets I haven't heard of, or invidia 6?00 chipsets.
And frankly I expect the missuse/confusion to only get worse considering how both pci-x and pci-express are pronounced.
No telling which the poster who said pci-x meant. I've seen it so many times for pci-express I'd completely forgotten about there ever being a pci-x, which I assume was mostly used in server MB's or short lived like most pre pci extensions/replacements to isa. I mostly deal with desktop machines so I don't run into the oddball/server items much.

Mycroft

Re:Why does RAM suck so much?

[Grishnakh]

That may have been important in the days where a gig of ram would cost you $1000.

But those days are long gone. It really doesn't matter any more.

Those days may be coming back, if RAMBUS manages to finally take control of the memory industry with its stupid patents. Then you can kiss all that cheap memory goodbye.

Re:Why does RAM suck so much?

[toddestan]

AGP came out when, about 1997? It's now 2005, and you can easily find new boards with AGP (I'd say the boards that don't include it are still a minority). I'd guess that it will take another year or longer for this to change.

Has any memory technology stuck around that long? (I will admit that PC-100 and PC-133 are pretty close though).

Rambus is NOT memory technology but

[zymano]

memory bus-like technology. It's not about memory . It's about wires that connect to memory. All they do is multiplex the lines. Nothing new here.

I would hope optic fiber interconnects could make a push by some tech company!

Wooooops. Maybe i will start one .

Re:Rambus is NOT memory technology but

[Zentac]

Just register yourself as a company and claim the patent, sounds like a modern and capable business plan to me, you probably won't have a hard time finding some investers either.

Rambus is BAD NEWS

[i41Overlord]

Aside from products and technology, has everyone forgot the kind of business that Rambus ran?

They pulled a fast one on the industry and then tried suing everyone in an effort to bully companies into licensing agreements.

They are a VERY shady company. Very unscrupulous and litigious. I would never deal with them knowing their past.

Another law suite

[Anonymous Coward]

http://news.com.com/Rambus+files+new+memory+suit/2 100-1004_3-5550397.html?tag=nefd.top

Rambus Shambus!

[mjh49746]

Not on my PC! If I wanted to get ripped off in the CPU price/performance ratio, then I would've bought a Pentium 4, and if I want to get ripped off in the memory price/performance ratio, then I'll consider Rambus. I'll hedge my bets on DDR2 as it matures and put my chips on AMD.

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)

TFA has short memory

[arekusu]

"The introduction of XDR however is reminiscent of RDRAM around 2000/2001. The technology provided significantly more speed than DDR and was promoted by industry heavyweights such as Samsung and Intel."

Actually, RDRAM was introduced around 1995, and was used by industry heavyweights such as SGI and Nintendo.

Sha! Right!

[slazar]

Um yeah, I think we the consumers have learned our lesson. Screw your patented BS, screw your jacked up licensing fees. Give me open standards that multiple manufacturers can follow, thereby giving me better prices.

Sorry...

[Anonymous Coward]

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.

Re:Sorry...

[Vo0k]

clever hardware that chopped up memory

That all takes time.
With speeds really nearing speed of light, distance from end to end of a typical DIMM becomes significant. Single extra transistor on the way introduces several % of delay. Serial delays things even more - chop the 64-bit signal into 10-inch long pulses (moving at speed of light!) and you're down to 1GHZ clock. And how much potential, how many extra electrons can you fit at 1.3V in 10 inches of a wire? And they must suffice to change polarity often of several transistors.

All these tricks would be viable if c wasn't 300.000km/s but, say, 3.000.000, if we had superconductors instead of copper, 1-atom transistors that can be triggered with a single electron and such. Nowadays adding another layer of indirection won't solve anything.

Re:Sorry...

[TheLink]

Uh isn't it already interleaved on some modern systems?

Also, on Opterons (and some Athlon64s) support dual channel RAM. That comes to the same thing...

headline:destroyed

[theCurteye]

slashdot just got creepy. i know it's just a troll, but....imagine? brrr

submarine patents

[Dink Paisy]

According to the judge in the anti-Rambus case, Rambus did disclose their patents, and their intent to charge for them. He went so far as to say that he would have charged the manufacturers for conspiracy to put Rambus out of business in order to obtain their IP, except that he believed that that was outside the jurisdiction of the case he was trying. That finding is likely making it much easier for Rambus to make good on their patent claims.

It's a tough act for Rambus to carry out; on the one hand, they have to deal with a small group of manufacturers who have (reportedly) been trying to defraud them and put them out of business, on the other hand, they have to rely on that same small group of manufacturers for all of their future revenue, so aggravating them too much is probably also a bad idea.

Of course, it's also possible that the judge was Just Plain Wrong, and Rambus was just trying to get submarine patents in place while they were a member of JEDEC. I don't have the expertise to make that judgement.

Re:submarine patents

[bani]

if that was the case, why was rambus convicted of fraud, and fined?

i know rambus got the fine reduced, but afaik the fraud conviction still stands.

Re:submarine patents

[HBergeron]

well afayk, you are very very wrong. The fraud conviction and fine were thrown out entirely and the judge in that case was roundly spanked by the most senior panel of patent judges in the country. That case is moving toward a retrial under terms mandated by the court of appeals in order to limit that judges mistakes.

Unfortunately for anyone who believes in speedy justice for all this bozo has now allowed new claims of fraud (in this case that Rambus destroyed discoverable documents) in order to muddy the waters again in what is supposed to be an intellectual property trial. Interestingly, apparently the Rambus attorneys have recently submitted to that same judge the documents that they were alledged to have destroyed, so we'll see what new creative line of attack he comes up with.

Perhaps getting your facts straight is difficult when you post at 5am?

Gillette just called. They want their razor back.

[Anonymous Coward]

Alright. Extreme Data Rate? C'mon, this is RAM we're talking about here, not a goddamned razor.

May as well call it Extreme Data Rate 3D Titanium Mach 5 Turbo 2k5 Deluxe Edition, or some such...

karma whoring linky

[Anonymous Coward]

http://www.extremetech.com/article2/0,1558,1188770 ,00.asp

Re:karma whoring linky

[uujjj]

Uh, next time you karma whore, make sure you log in so you actually get your karma.

Re:Gillette just called. They want their razor bac

[Walterk]

Hey, good idea. We shall be changing the name ASAP.

Sincerely,
Rambus CEO

if it increases latency, "no, thanks"

[Moraelin]

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.

Re:if it increases latency, "no, thanks"

[renoX]

> 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.

No problem, to reduce latency RAM makers should just increase the speed of light..
Easy!

Not again

[Zordas]

I won't fall for this again. Back in 2000 I bought a spanking new 1.8ghz system w/800mhz RDRAM. Even thought my Asus motherboard would obly operate at 400mhz for ram. I was hoping that eventually I'd be able to upgrade someday. But nooooo. 1 year later the memory was worthless and I had to buy DDR ram for next motherboard. Fool me once .......

As Bush might say...

[thaneross]

Fool me once, shame on ... shame on... you... Fool me -- you can't get fooled again!

Latency

[dpilot]

There's another aspect of latency here that's being ignored. Here and elsewhere in this thread tree folks are talking about circuitry issues, like the memory controller, DRAM itself, DDR, etc. Those are all valid, but there's one more that's being neglected - wires, drivers, and receivers. By simply putting the DRAM somewhere away from the CPU/Northbridge, up on a DIMM socket, you take a big hit in latency. Even getting Zero-access DRAM wouldn't speed things up that much, because of the physical-related delays.

Oh, I agree with your abstraction comment.

Putting faster things into an FBDIMM just won't do that much, because the speed is physically in the same spot. I did an extensive study of this back prior to 1990 and found these results, and the consolidation of L2 and even Northbridge onto the CPU shows that it's still valid, today. Main memory is going to be slow. Main memory is always going to be slow, because that's a side effect of being "big". Main memory is always going to be "big" as long as the appetite for bits exceeds what can fit onto one chip. Learn to live with it.

Incidentally DRAM latency grows beyond minimum the moment you multiplex row and column addresses. There is a Trcd(max) spec where access is purely row-limited, but in practice that's just about impossible - access is almost always limited by Column access. Trade speed for pins.

Beyond that, even SDR traded off latench for bandwidth, compared to EDO. (I've designed both.) I don't think DDR is that bad a deal, compared with SDR, though I haven't actually done a DDR design, myself. At the very least, DDR offers the half-cycle latency options, and the DDR designs have been architected to scale far higher in frequency than SDR ever was.

Re:Latency

[TheLink]

DRAM slowness doesn't bother me as much as HDD slowness.

Decades later and we still have access times in the order of 10ms... That really really sucks.

DRAM isn't that bad because the SRAM caches work pretty well in many cases - e.g. you have a loop zooming along at near CPU speed (in SRAM), reading and writing processed data out at DRAM speed. That's fine because the loop often isn't fast enough to move data in and out at SRAM speed.

You are more likely to hit the HDD speed limits first (or run out of DRAM space - but that's another matter). Then you need big disk arrays...

Re:Latency

[Grishnakh]

DRAM slowness doesn't bother me as much as HDD slowness.

Decades later and we still have access times in the order of 10ms... That really really sucks.

First, if DRAM were far faster, computers would be far faster. Memory performance affects CPU performance far more than disk performance does. The slowness of disks can be made up for using DRAM cache, just like SRAM cache makes up for the slowness of DRAM.

Second, modern hard drives are down to about 8.5ms, which is a lot better than the 28ms I remember being common in 1990. Of course, this is only a linear improvement, but you really can't expect any better when you're still dealing with mechanical drives that haven't changed much in design over the decades, except for the information density on the platters, and the physical size which is slightly reduced.

The coming 2.5" drives (desktop, not laptop) should have lower access times. But don't expect anything really fast until we move to micro-mechanical drives; we can't do that now because they wouldn't store much data.

Re:Latency

[dpilot]

Reminds me of an old concept called "Single Level Store."

With SLS, there is essentially only "memory," defined by the disk space. The DRAM that we think of as main memory becomes just another level of cache - a cache of the full memory space, which is implemented on disk. (Presumably the full memory space could be implemented in other ways - across a cluster, SAN, etc.) Part of implementing this is a thing called "inverted page tables" that were part of IBM midrange systems beginning with the System/38 and also on the Romp and POWER series. (I don't know if it's still on current POWER or POWERPC chips.)

Re:Latency

[dpilot]

I tried to express that it's not so much DRAM itself as the fact that it's packaged separately that causes the delay. I won't argue that the DRAM isn't "slow" as to say that even if it had no latency, you'd still be waiting almost as long because of buffer, wiring, cross-chip, and connector delays necessary to put that DRAM up on a DIMM.

It's also worth understanding the driving forces behind DRAM "slowness". First off, DRAM technology is driven by price and density, with performance being a distant third shared with power and data-retention interval. (How long between refreshes) DRAM doesn't get fancy-pants fast transistors, they get CHEAP transistors. For that matter, the access transistor for the cell itself simply CAN'T be fast, because it has a far more important job - it has to shut OFF. When you're talking tens-of-thousands of electrons, you can't afford to carelessly lose of any of them. I know /. articles talk of storing a bit on the spin of one electron, but we ain't there, yet. Second, the basic DRAM sense is a charge-share operation. It's not current flowing in the conventional sense, it's transient. Furthermore, it involves waiting long enough to get enough charge to sense, yet not so long as to appear too "slow".

Every now and then, someone wants to come along and make "fast" DRAM. DRAM can be made faster, there are some simple tradeoffs that allow it to be done. But people continue to buy primarily the cheap stuff.

Re:Gillette just called. They want their razor bac

[RogerWilco]

You forgot Super Hyper Ultra and "Gold"

From a Business Perspective

[Deliveranc3]

This is probably one of the last chances to get XDRAM included in the on die memory controllers for AMD and Intel systems for the next 5-10 years.

After AMD's success Intel will follow suit and with both the major players doing things the same way the market will become quite stable.

However if XDRAM can impress before INTEL get's the mem controller on die, then they may be included and have 10 blissful years of monopoly, Intel made that mistake before, (in my mind it plays out like a MicroSoft tie in deal).

Anyway 2c

*We* Should Not Let Them

[Bob9113]

We are a big section of the opinion makers in computer hardware. We have the ability to affect the public opinion on XDR. To a large extent we were the ones most adversely affected by the last round, and we are the ones who can shift public opinion now.

This should be like a usenet death penalty. The free market is there to reward those companies that serve their customers and punish those that do not. It is a good system, but it tends to have a short attention span. Tell your friends. Tell your purchasing deparment. Keep Rambus from coming back from the dead and send a message to other companies who think about abusing submarine patents. It's the same thing as harsh criminal sentencing, except that the free market has a far better track record of responding to example punishment (that is to say; if you support harsh criminal sentincing, you should support this on the same ideological grounds, and if you don't support harsh criminal sentencing because it doesn't work, you should still support this because it does).

Re:Pathetic attempt at FPing-Apple Core.

[Fulcrum of Evil]

Kind of like Apple?

Apple delivers value for price and doesn't really charge that much more in the first place.

I don't know where you're getting that

[dusanv]

If you don't mind submitting some links that would be great. Read this article. It clearly states that Rambus was convicted by a jury of submarining patents into memory standards. It was overturned by a superior court because JEDEC doesn't explicitly require disclosing patents which is a technicality in my vocabulary. They definitely didn't come forth with those patents and tried to enslave the whole industry into paying them royalties. They are the bad guys in my book and I will not touch their crap with a ten foot pole.

Re:I don't know where you're getting that

[bani]

exactly. regardless of what was required by JEDEC bylaws or not, what rambus did was truly evil.

Re: I don't know where you're getting that

[MotiveForce]

Here are some problems with that scenario:
1) Rambus had already presented their technology to most of the memory manufacturers individually before Jedec, so they already knew about it (even though Rambus was not allowed to present it at Jedec.)
2) As I understand it, the actual standard for SDRAM developed at JEDEC does not require the use of technology on which Rambus has patents. However, all of the actual implementations (the ways that SDRAM was actually made) DID infringe on Rambus' patents. So, technically, you could make SDRAM without infringing, but no one did because it wouldn't work worth a darn. But the standard developed at Jedec while Rambus was there (sitting quietly in the audience without presenting anything) did not infringe. (Although it seems like Rambus themselves weren't entirely sure at the time if it was going to or not.)
3) Rambus left Jedec, and announced to Jedec officially that they thought there would be potential issues involving their patents. Long AFTER Rambus left Jedec, the DDR standard was developed, and even later DDR2. Yet all of the DDR and DDR2 that is made now infringe on Rambus patents. Are they still "submarining" patents? The truth is, there had not been, and still has not been, any viable alternative invented.

If you are interested in learning about this subject try here:
http://www.ftc.gov/os/adjpro/d9302/040223initialde cision.pdf
Note - that link is to the FTC, and is a 300+ page pdf of the decision written by an FTC judge after he spend months hearing a trial about this situation. This is not Rambus propaganda. The FTC investigated Rambus at the behest of Micron. If you want an exhaustive, unbiased source of information, this is it. There is a summary section at the end that you can start on. If you read through enough of this, as I have, you can see that in fact it was the memory manufacturers who were purposely screwing both Rambus and the public, and a lot of what you have read in the trade press is propaganda spread by them.

Apples to oranges

[DSP_Geek]

Why is everyone comparing the bandwidth of XDR with DDR, which has been around since the dinosaurs? The proper performance face-off is with GDDR3, which at least has the merit of being introduced this millennium. The peak bandwidth difference between XDR and GDDR3 is not so huge - about 20 to 30%, or about the same as RDRAM and DDR, which turned out to be almost nothing when RD's greater latencies were taken into account. I suspect, on no good grounds whatsoever, that XDR is Yet Another high-latency spec from the Rambus brain trust.

Same thing as the Pentium 4: just like a late 60s Detroit muscle car, goes real good in a straight line, slides all over the place when you make a turn.

Re:Boy have you people been snowed...

[DSP_Geek]

Hmmm. Two Anon comments boosting Rambus within ten minutes of each other? I smell Astroturf.

On the other hand, for a quick snort of reality:

http://it.slashdot.org/comments.pl?sid=137314&ci d= 11479521

FYI

[TheLink]

PCI-express != PCI-X

Uh.

[TheLink]

You already have tight CPU-SRAM memory integration. It's called CPU cache.

As for 128MB level 3 cache, some servers do have that.

If it's worth it, they often do put the stuff in.

It's just like battery backed RAM HDDs. If DRAM was cheap enough more of us would be using that instead of klunky spinning discs. As it is, it's cheaper for most people to buy GBs of RAM and use that as disk cache AND space to _execute_ programs, rather than buy the niche RAM-HDD product and not be able to execute programs directly off it.

Having the SRAM as cache makes things more flexible.

ancient? You newbie . . .

[hawk]

>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.

"ancient"? *gasp* [*insert chest-clutching sequence here*]

I knew those new-fangled sixteen bit machines with their wait states were a bad idea. Back to the 8 bit machines! No wait states! In fact, we can pair the 6502 with the 650 and have *two* processors running all ot on the same memory.

64k should be enough for anyone. Especially if you have a second double sided, double density 5.25 drive.

hawk, glancing around for his cane and rocking chair

Microsoft...

[The Creator]

RAM.Net

Re:I can feel my wallet opening already...

[toddestan]

I just bought a computer with a gig of it for slightly over $200 used. I was expecting to find SDRAM, so imagine my surprise when I popped open the case.

Atleast I have no plans to upgrade it. Plus it's fast.