6 ms·
Visualization of L1, L2, Ram and Disk latencies [gif]
- mcav 17y agoIt'll be nice when SSDs come down in price/GB. Should help make day-to-day work seem just a tad quicker.
- Retric 17y agoI can't find good numbers, but it looks like SSD's are still around 0.1 millisecond's which is still 100,000 nanoseconds. And 1/1000th the access time of RAM if if they are 100 times faster than HDD's. Most people don't really notice that big of a jump from HDD to SSD's and, I don't see it being as much of an issue for a while due to the increasing ram and cache sizes.
- mcav 17y agoSome videos show that SSDs could improve experience in terms of booting, launch, etc: http://www.youtube.com/watch?v=pJMGAdpCLVg http://www.youtube.com/watch?v=pJMGAdpCLVg It's that kind of speedup I'd like to see -- disk-heavy tasks that don't peg the CPU.
- leif 17y agoThe major improvement coming from SSDs is that seek time no longer kills you. People will notice a difference going from random access on a rotational drive to random access on an SSD; sequential access, not so much.
- Retric 17y agoMy point was while SSD seek time is 1/100th HDD seek time you don't get anywhere near that big a jump. Because, while a HDD might take 100x as long to get you the first bit, HDD and SSD take about the same amount of time to read the rest of 4kb the sector.
- herf 17y agoSSDs vary a lot by write speed. Most today are slower than HDD for write throughput. (Intel's SSD drives are actually fast, but expensive.) This will get figured out and make a big difference. But still no comparison to RAM.
- deleted 17y ago[deleted]
- deleted 17y ago[deleted]
- jsz0 17y agoMoving to SSD is a very noticeable performance bump. In my personal experience it has been one of the better upgrades I've ever done. The performance gains are across the board whereas CPU/RAM upgrades these days only benefit you if there was a CPU/RAM bottleneck in the first place. If you happen to have a fairly good system to star with an SSD really opens things up.
- jws 17y agoDon't try to view this on an original iPhone. It crashes safari.
- malkia 17y agoAll I see is a red-bar strip. Is this an animation or something (I've tried Mozilla, Safari)
- yan 17y agoZoom in all the way and look on top
- randomwalker 17y agoI've been HDD-free for a few months now; I can't imagine going back. It's not just latency that's an issue for me, it is also reliability (I've had 6 HDD failures in the last two years in various devices around the house.) I also worry less about damaging something if I drop my laptop. For my latest work project (I do scientific computing), I realized it's easier to do it on my laptop instead of the workstation. Since my laptop has an SSD, I can just use the filesystem as my database. This means that I can have have millions of files (literally, millions) lying around and process them using the good old Unix shell. It greatly reduces the development time compared to using a database. Just for giggles I tried doing this on a machine with a hard drive, and it was more than one hundred times slower.
- lsc 17y agoHave you tried it on a box with a HDD and an adequate amount of ram? I would think that on modern file systems with ordered metadata writes (or journaling) like ext3 or ffs with softupdates, so long as you had enough ram, disk speed wouldn't matter all that much so long as you can keep everything in cache. SSD is great, the problem is that the good SSD costs something like $15 per gigabyte, and good registered ecc ddr2 ram costs just over $20 per gigabyte. Sure, in applications where consistency across power-loss events is a huge deal, ssd is the right answer, but for most applications, buying a whole lot of ram is often faster and not that much more expensive.
- randomwalker 17y agoRAM was not the issue. The reason for the slowness, as I understand it, is rather that different files are spread out in different areas of disk, even if they are in the same directory. This is considered a feature, and I guess it makes sense under normal access patterns. So accessing a million files (even to load them into memory for the first time) would require the same order of disk seeks, and takes forever. I might be simplifying a little bit, but this is my understanding. Could I have re-written the code by messing around with inodes and other low-level details so that it accessed the files in physical order? Probably. Was it worth my time, rather than using an SSD? Hell no. I agree that SSDs are still a tad expensive for the average Joe. For most hackers, considering that we spend most of our work hours in front of a computer, I feel that the added productivity from an SSD is easily worth the investment.
- kazuya 17y agoIn case you are too lazy to enter the URL at the top: http://duartes.org/gustavo/blog/post/what-your-computer-does-while-you-wait http://duartes.org/gustavo/blog/post/what-your-computer-does... There you can find more nice figures.
- gourneau 17y agoThe post links to a 114 page paper titled 'What Every Programmer Should Know About Memory" take can be found here http://people.redhat.com/drepper/cpumemory.pdf http://people.redhat.com/drepper/cpumemory.pdf
- patio11 17y agoAnyone like physical analogies more? If you convert them into relative masses: L1 cache: a squirrel (1kg) L2 cache: a mid-sized cat (~5 kg) RAM: a tall, well-muscled man (~80kg) Hard disk: one hundred blue whales (100 * ~130 metric tonnes) This is what I mean when I say "It doesn't matter how fast your language is, you're just racing to get to wait on I/O faster." P.S. Let's extend the analogy to include two other common factors: Typical round trip to database: the combined mass of every ship, plane, and person in the USS Nimitz' air group... with room for another two fleets or so after you're done (150 ms ~ 1.5 million metric tonnes) Time for user's computer to render a web page of medium complexity: worldwide demand for cement in 2009 (2 seconds = 20 million metric tonnes) But please, spend time optimizing your string concatenation... because that is going to help ;) [Edited: Revised and extended because I introduced a conversion error or two and then compounded them. Word to the wise: mental conversion to fractions of blue whales not advisable before morning coffee.]
- sho 17y agoI think you are using different numbers from those depicted in the graphic, in which RAM is "only" 83 times faster than L1 cache, or under a kilogram if we go with the L1 hummingbirds @ 10g, and the cat would be 47 grams. Maybe you meant to start with 1 kilogram? : D
- patio11 17y agoGah, I really need to put my numbers on paper when doing repeated conversions or errors creep in. You're right, it is pretty borked. Give me a second...
- kazuya 17y ago> Give me a second... L1$: a second Hard disk: more than five months
- sho 17y agoThat really is incredible isn't it. I don't mind saying I have difficulty comprehending - really comprehending - such large magnitudes. Great to hear it in different formats though. I can stare at numbers all day and still not really get it, but the difference between a second and 5 months is as subtle as a punch in the nose. Good stuff.
- grinich 17y agoI feel like I need a SSD just to deal with this image. How about like 3 lines of CSS?
- sho 17y agoLook, it is 54 KB. That is not large. Perhaps with some effort it could have been slightly smaller but the author is probably optimising for a different metric.
- grinich 17y agoYou're right. 53,966 bytes and not one larger. I wonder why it chokes up my browser. But seriously, if you're going to use a GIF, at least make it animated.
- scorxn 17y agoGranted, the CSS wouldn't require zooming in, and the citation link would be usable.
- kinetik 17y agoThe image dimensions are 1120x13800, so it's 59MB uncompressed in memory.
- lsc 17y agoNice. it makes it real clear why caching disk to ram (as all modern *NIX variants do) is such a huge win, and why you should always load up your servers with as much ram as you can afford. Sure, CPU contention can slow things down, but it's usually not the 'fall off a cliff' performance degradation that hitting disk (rather than hitting ram cache) is.
- sho 17y agoI'm sure there's an excellent reason, but the first thing I think whenever I see something like this is .. why doesn't intel (or whoeever) load up the CPUs with more L1 and L2 cache? Are there really diminishing returns so quickly after 6MB, or would the size increase make the expense not worth it? And is it impossible to make it modular and expandable? It would be interesting to see some account of the cache size / die size cost / performance trade-offs.
- wmf 17y agoIt's commonly accepted that the cost of a chip is super-linear in its area but performance improves sub-linearly with cache size, so there is definitely a point of diminishing returns. Processor vendors analyze cost/performance tradeoffs in detail, but they generally don't publish anything.
- sho 17y agoYeah, that's what I figured. Be nice to see some numbers though. Not like I have a hope in hell of getting anything I write even into 6MB .. sigh.
- ajross 17y agoThey do: http://images.google.com/images?hl=en&q=nehalem+die http://images.google.com/images?hl=en&q=nehalem+die Nehalem is about 70% cache. Most of it is the shared L3 between cores. There are physical limits to how large a cache can be and still run synchronously. The L1 is still tiny (64k, split between instructions data), and it's really not feasible to make it larger without affecting clock speed. But if you drop just a little bit and pay a latency cost, you can stick a 256k unified cache on each core. Then they all talk to the 3M shared "uncore" cache. But to first approximation, a modern "CPU" is entirely SRAM.
- paddy_m 17y agoWhat is the difference between L1 and L2 cache? I know that L2 caches are generally larger. Is it more expensive so far as silicon real estate, to make 1k of L1 cache vs 1k of L2 cache? The last I heard, both L1 and L2 cache were sram based which used 6 transitors per bit. I also remember that ram takes either 2 or 4 transitors per bit + a capacitor. If L1 and L2 cache take the same number of number of transistors per bit, what is the difference?
- vannevar 17y agoHow about adding ethernet and wireless latencies?
- TheSOB88 17y agoWhy doesn't this take into account the size of the block you're getting back? 1 pixel from the L1 gets you less data than 8 from the L2, etc.