L1 - You've already started eating the sandwich, and only need to move your mouth and take another bite. (2 seconds)
L2 - There is a sandwich on the counter, so you need only find it, pick it up, and begin eating. (10 seconds)
RAM - You're near the fridge, but you need to open it and quickly throw together a sandwich. (3 minutes)
HD - Drive to store, purchase seeds, grow seeds, harvest etc. (1 year)
In this analogy, you are busy while you are making your sandwich (because you are putting it together from stuff you got from your fridge).
In the library-with-free-delivery-service analogy, you can do other work while you wait for data from the library/RAM to be delivered.
Modern superscalar processors can re-order non-dependent instructions while waiting on a memory lookup, and that is what the free-delivery-service aspect of the analogy illustrates.
CPU = person (researcher at library)
RAM = bounded physical space on desk
Swap = cart for stacks
Disk = the stacks (requiring scheduling of the elevator)
In my mind, the discussion of second/nanosecond is unimportant and makes this seem more technical than it needs to be to illustrate the point that "fetches from (non-SSD) disk are very slow and waste a lot of time." But this doesn't seem to be quite as focused as "A complete idiot's guide to the main components in a computer and what they do." (though I'm not sure that it's either time scales or components or SSD)
CPU to main RAM: actually about 150:1; more like 30:1 in your analogy.
Main RAM to HD: actually about 200,000:1; more like 120:1 in your analogy.
The reason why "the discussion of second/nanosecond" is worth having is precisely that if you just say "very slow" and "a lot of time" then you're likely to think about ratios of the sort in your analogy, when the reality is much much much worse. (Extreme case: HD to CPU registers. Actual ratio: about 30 million to 1. Ratio in your analogy: about 4000 to 1.)
I disagree. The second/nanosecond discussion illustrates the scale of the difference. I can understand the difference between a few seconds and a few years (just about), and it puts it into perspective.
> "fetches from (non-SSD) disk are very slow and waste a lot of time."
Saying "It's very slow" isn't very helpful. I want perspective. Also the point is that the time is perhaps not wasted is an interesting one.
The original analogy is intelligent, (accurate?) and puts this into perspective for developers (and potential SSD customers!).
I wanted to say that that was within an order of magnitude to the cost of a simple system call, but it looks like system calls are much much faster than my intuition suggested, and they're in the range of RAM access.
And yet, if you can wait three years for the first wooden
boat, it can often be at the head of a convoy which will
keep you busy for many thousands of years, sometimes even
orders of magnitude more if you take a minute to request
that another convoy sets out.
- James Gray
Thanks for posting. A very insightful analogy, really putting things into perspective.
As an ASIC guy, I like to occasionally casually mention to software guys that at 3GHz, light travels about four inches in one clock cycle, and it frequently really blows their minds.
180,000mi/sec * 5280 * 12 = 11404800000 / 3,000,000,000 = 3.8inches.
Extending that a little further... on a 45mm i7 chip going from one end to the other and back would be ~3.5inches of travel. Gives me an idea of how much of a constraint packaging is.
speed of light = 3 x 10^8 m/s
3 GHZ = 3 x 10^9 /s
So 3 x 10^8 / 3 x 10^9 = 0.1 metre = 10 centimetre = okay, 3.9 inches
But then metric always saves your ass. Back in physics class, they'd ask you how deep the well was if you dropped a stone & heard the water splash in 10 seconds. Before the American students could even begin their work, all the Indians would yell "500 metres!" And that's cause the gravitation constant is 10, so one half 10 times 10 times 10 is 500.
It's probably much less than that because paths in the CPU aren't straight lines. Also the i7 is a 4-core die, so it's unlikely that any signals need to go across the entire die in one clock. (Besides the clock signal, of course).
Check out the animations under "Clock Distributions" (numbers 19 to 25. It shows how the propagation of the clock across the die is affected by frequency (When a part of the fabric/tree is up or down it represents 1 and 0 respectively).
My favorite is the SymTree and Non-Uniform SymTree (23 and 24) which shows how having a non uniform load at various parts of the chip and a fixed tree structure affects how long each part of the chip is at a 1 or 0 state (i.e. a low load part of the chip will spend more time at a stabilized 1 or 0, while a heavy capacitive load at one part can not even reach a true 1 or 0).
Extending that thought to multiple cores/threads. Comparable to a small business in a way? You have one guy who can go tell other people to do certain tasks. They take anywhere from a few minutes to a few hours. You can set it up so that there is a task list of things for people to do so that you don't have to continually reassign each one, just tell them to pick up the next thing to do. It's much harder and requires more organization, but ultimately, like the division between a small business and a one man show, you get more shit done with multiple people/threads/cores working in parallel than one single unit working by themselves.
Thanks for posting this.
Depends on the architecture, actually. What you're describing is a lot like the Cell processor design. For x86-based processors, it's much less organized than that, because each core is, for all intents and purposes, effectively an independent processor.
The best analogy for multithreaded programming I've come up with is a(take a drink) car factory. Each core is a generalized assembly line that is capable of producing any part, but it takes time to switch to a different task. The end goal is a car, which means that you can have one core working on the transmission, one core working on the interior parts, one on the exhaust, and one working on the motor. If you can balance them out, you can have all of them finish around the same time. But if you're trying to actually make a car, you're going to end up with some overhead to finish the entire thing. There is some overhead where the body is made, and all the parts that were produced by the other lines are actually put into the car.
Compared to a single-assembly line factory, it's possible to make cars much faster with multiple lines. But there will always be some percentage of time that you cannot split across multiple cores.
Tom's Hardware suggests that Crucial's m4 series are faster than OCZ Vertex 3's, and don't come with a horrendous approval rating. A 256Gb m4 is $319 on newegg .
Intel's new 520 SSDs appear to have given them a proper SSD instead of the floppy-disc-like performance of the 510. Though its $499 for 240gb. 
All drives have failures, and while it sucks to be the one that gets the dodgy drive, there will always be someone who can post "it didn't work for me". However, the OCZ Vertex have an unusually high number of "It didn't work for me" reviews. Is it a stitch-up? It'd be easy for "a motivated third party" to buy 27 drives off newegg and post negative reviews. It'd also be in OCZ's interest to fan the flames of doubt on the SF2281 as they are releasing new SSDs based on their own, newly-purchased, Indilinx controllers. But taking off the tin-foil hat, it does look like Vertex 3's have problems.
Why did I recommend the OCZ? AnandTech writes about OCZ products a lot, and I trust them. I wrote the post a few days ago thinking that mostly my friends would read it. It only occurred to me today to post it on hacker news, when I saw that I got like 7 +1s from friends.
"Back in October SandForce announced that it had discovered a firmware issue that resulted in unexpected BSODs on SF-2281 drives on certain platforms. Why it took SandForce several months to discover the bug that its customers had been reporting for a while is a separate issue entirely. SandForce quickly pushed out the firmware to OCZ and other partners. Our own internal testing revealed that the updated firmware seemed to have cured the infamous BSOD."
"As luck would have it, our own Brian Klug happened to come across an unexpected crash with his 240GB non-Intel SF-2281 based SSD two weeks ago when he migrated it to another machine. The crash was an F4 BSOD, similar in nature to the infamous BSOD issue from last year."
Oh. This was written 2/6/12.
"Whatever Intel has done with the 520's firmware seems to have fixed problems that still remain in the general SF-2281 firmware."
"While it's nearly impossible to prove most of this, the fact that we're still able to reproduce a BSOD on the latest publicly available SF-2281 firmware but not on the SF-2281 based Intel SSD 520 does say a lot about what you're paying for with this drive."
I don't expect that I'll receive an apology for being called an unethical shill.
I'd still love to see some statistics on failure rates. All this anecdata is obnoxious for a buyer to wade through.
After the 6th time of it corrupting various parts of my filesystem (often the catalogue and other important parts), I'm returning it to Amazon.
It was twice as annoying because I had to re-rip open my iMac to get at it. I think I will be exchanging it for an OWC Mercury Extreme.
I guess hardware roulette with storage still has the worst odds...
Less jumping to conclusions, please.
By the way, get an Intel or a Samsung when your Vertex fails...
Of course you can also get a smaller SSD and or use it as your only disk drive, but they do really make that old file server idea really appealing especially if you have more than one computer.
Anyway, I was going for human reaction time of about 0.15sec real world. So about 4.75 years in the analogy.
The size of each circle would be relative to the avg. amount of time needed to move data to the CPU. To me this would be more intuitive than charting system data.
I've owned 3 SSDs and have had 2 failures, so far, over 2 years. In the past 20 years, I've owned around 100 hard drives and have had only 4 failures.
This is the achilles heel of the SSD for me. I've gone back to spinning rust because I need the reliability more than I need the performance.
The performance was nice, very nice. But having to restore from backup is something that I do not like doing every year. I'd like to do it once a decade or less.
Until then, I'm no longer using SSDs.
I did a bunch of research into why SSDs fail and inevitably it seems to be software bugs due to the SSDs being clever. I suspect the Samsung SSDs that Apple uses are not clever and thus do not fail. I will use an SSD if it comes with an Apple warranty. But I had an intel SSD fail, and I had a Sandforce based SSD fail. Both catastrophically with zero data recovery (fortunately I had backed up, though in both cases I lost a couple hours of work for various reasons.) In both cases, near as I can tell, the SSD had painted itself into a corner-- it actually hadn't been used enough to have flash failures sufficient to be a problem, let alone in excess of the extra capacity set aside. Nope, it was a management problem for the controller that caused the failures. These kinds of problems can be worked out by the industry, but give that the market has existed for 3-4 years now and we're still having these kinds of problems, I'm going to wait before trying something clever again.
 The one that is still working is in my cofounders machine, and I'm dreading the day that it too fails. I am afraid it is just a matter of time, and as soon as we can reshuffle things they'll be using spinning rust again as well.
One (milli-)second the drive is totally fine, then the next it is just gone. Magnetic disks usually give some warning, and usually fail for mechanical vs. controller reasons.
I still use SSDs, but am constantly wary, especially in the first month of a new drive's service.