Live data from Hacker News

RAMCloud puts everything in DRAM

zdnet.com

31–40 of 42 posts

Re: RAMCloud puts everything in DRAM

#31
post #17

"Imagine a world where data layout doesn’t matter, where apps are optimized for sub-millisecond storage, where 100 byte I/Os are faster and just as efficient as 8KB I/Os. The architectural implications are huge and would take a decade or more to get our heads around." Umm.. I've worked with in memory data structures (who hasn't?) and yeah, layout DOES matter. Especially if your data structure is larger than a cache l…

"Umm.. I've worked with in memory data structures (who hasn't?) and yeah, layout DOES matter. Especially if your data structure is larger than a cache line."

That's only compared to the speeds gained by different memory layouts.

But compared to hard/solid state disks (which is the whole point here) the difference is less than insignificant.

Re: RAMCloud puts everything in DRAM

#34
post #17

"Imagine a world where data layout doesn’t matter, where apps are optimized for sub-millisecond storage, where 100 byte I/Os are faster and just as efficient as 8KB I/Os. The architectural implications are huge and would take a decade or more to get our heads around." Umm.. I've worked with in memory data structures (who hasn't?) and yeah, layout DOES matter. Especially if your data structure is larger than a cache l…

>"Imagine a world where data layout doesn’t matter, where apps are optimized for sub-millisecond storage, where 100 byte I/Os are faster and just as efficient as 8KB I/Os.

with latency not being absolute 0, 100bytes I/O will always be less efficient the 8K I/Os. For example, with 300Mb/s and 0.01ms latency the throughput would be 10M/s vs 220M/s.

Re: RAMCloud puts everything in DRAM

#35
post #17

"Imagine a world where data layout doesn’t matter, where apps are optimized for sub-millisecond storage, where 100 byte I/Os are faster and just as efficient as 8KB I/Os. The architectural implications are huge and would take a decade or more to get our heads around." Umm.. I've worked with in memory data structures (who hasn't?) and yeah, layout DOES matter. Especially if your data structure is larger than a cache l…

>"Imagine a world where data layout doesn’t matter, where apps are optimized for sub-millisecond storage, where 100 byte I/Os are faster and just as efficient as 8KB I/Os. with latency not being absolute 0, 100bytes I/O will always be less efficient the 8K I/Os. For example, with 300Mb/s and 0.01ms latency the throughput would be 10M/s vs 220M/s.

"100bytes I/O will always be less efficient the 8K I/Os"

Not if only 200 bytes of that 8K are relevant. It depends on the rpc overhead, but the small io's may be more efficient. Which is why you see them researching changes to the networking stack.

"300Mb/s and 0.01ms latency the throughput would be 10M/s vs 220M/s."

When you write numbers on a napkin this is true. When you're talking about real systems that are both concurrent and scheduled in quantized slices you'll see much more complex behavior.

Re: RAMCloud puts everything in DRAM

#36
post #10

Is "DRAM" the new name for "RAM"? Anybody know why the change in terminology? In which circles is this standard?

They're probably trying to distinguish it from flash "memory" (which is usually accessed using a storage interface).

Re: RAMCloud puts everything in DRAM

#38

Am I mistaken, or is this what Violin Memory, FusionIO, and there is a 3rd company that is doing this already...

That's flash, accessed through a block device interface with 10-100 us latency. RAMCloud is using DRAM with <10 us latency.

Re: RAMCloud puts everything in DRAM

#39
This sounds a lot like SAP's in-memory database, HANA:

"SAP HANA is an integrated database and calculation layer that allows the processing of massive quantities of real-time data in main memory to provide immediate results from analyses and transactions."

http://www.forbes.com/sites/sap/2011/10/04/why-sap-hana-is-a...

Post reply on HN