Shane wrote: > As for more indirect solutions like RAM disks... I think you would > loose at least a factor of ten in speed compared to simply accessing > system memory directly as you would need to go through the file system > and out to an external device with RAM in it pretending to be a disk. > If I remember correctly the fastest disk interfaces you can get for a > PC are in the order of 100 MB per second while system RAM is more like > a few GB per second. So if you need really high speed then RAM is > perhaps your only option I think.
For RAM, as with disk, it is more about latency than bandwidth. Even with contrived codes, you can't drive RAM at 100% bandwidth even on architectures with extremely low latency (e.g. Opterons), and on more average architectures (e.g. PPC970) it is not even remotely close to theoretical. For big memory systems a la ccNUMA, the performance is less. A big part of the reason is that the latency limits the number of requests to core that you can make per second regardless of the theoretical bandwidth. The disk may have less bandwidth, about 250MB per channel on a normal high-end HBA, but it can drive that close 100% and it is trivial to run multiple channels in parallel which will get you in the same region of real RAM bandwidth-wise. The big downside is that it gets this performance because it works on big chunks of data compared to real RAM, so the number of discrete fetches per second will probably be an order of magnitude less than system core even under ideal circumstances. I think the biggest argument against using a big RAM disk array is that the HBAs and drivers are optimized for very different types of things than a RAM extension. When you get into big ccNUMA systems, the real memory latencies start to creep within spitting distance of network DMA, arguably the most interesting low-cost alternative. j. andrew rogers ------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
