Slashdot Mirror
Mass Storage Leaves Microchips in the Dust
Roland Piquepaille writes "This article from Wired Magazine looks at storage with a new angle. 'Right now I am sitting in front of a whirring 60-gigabyte hard disk that cost less than $100. Do the math: If back then 10 megabytes cost $1,000, then 60 gigabytes would have cost x, where x = $6,000,000 and "back then" = 18 years ago. I'm sitting in front of $6,000,000 worth of mass storage, measured at mid-1980s prices. We have Moore's law for microprocessors. But who's coined a law for hard disks? In mass storage we have seen a 60,000-fold fall in price -- more than a dozen times the force of Moore's law.' DeLong also looks at a non-distant future when a $100 mass storage device will hold a full terabyte. He also thinks that with disk space becoming cheaper and cheaper, we'll be tempted to archive everything about ourselves, including pictures and videos. This is in fact the goal of the Gordon's Bell project, MyLifeBits. You can learn more about the MyLifeBits project by reading this NewsFactor Network article. Check this column for more details."
microprocessors have gotten faster and faster. hard disks have not.
It would be much better if we could combine this growth in the industry, into producing CF cards that can hold 2+ GB, and give us mass storage on small microchips.
Saskboy's blog is good. 9 out of 10 dentists agree.
Nah, not really. There is only so big an app can get in terms of code, and it's way, way less than a small HD can do. For consumers, who are using more than 25% or so for their drive, it's likely digital media that's doing it. MP3 files, and especially video. Textures and videos in games. Tutorial files for media apps. That kind of stuff.
.app, and you'll likely find less than 25% of the total file is being used for application code. The rest is multilingual help, graphics, sounds, etcetera.
Crack open your average 20 MB MacOS X
My video compression blog
... if you think carefully (or even casually) about the claim.
The guy is confused (or intentionally spinning) about storage capacity and price. I believe Moore's Law says only about the processing speed. In that case, we replace processing speed with disk capacity, and we extrapolate from the data he gave (which is prolly questionable):
10MB * 2^(18yr / 1.5yr) = 40960MB ~ 40GB
So the disk capacity is not far from Moore's Law (which is not really a law, just an educated guess with observation) prediction.
You can derive all kinds of conclusion when you compare an apple to a chair. It doesn't mean that you cannot compare an apple to a chair, it is how do you validate that conclusion. E.g., if we want to see the relative size of apple v chair, sure, the comparision is valid. But if we want to compare the taste, or the color, well, we need a little more qualification, don't you think?
Sensationalization--works on enough people to be very effective tool in mind control.
Cheers,
e.
If prices fell by 60000 times over 18 years, then we're looking for the solution of the equation: x^18 = 60000, which implies x = 1.84 years = about 22 months. So prices fall in half every 22 months (assuming it's exponential). Moore's law says transistor density doubles every 18 months. It's not that much different, although it does make a huge difference over time.
You hear people refer to the assumption that electronics will keep getting cheaper and and cheaper as "Moore's Law". Nit-pickers hate this, insisting that "Moore's Law" only refers to the number of transistors on a chip. But even casting Moore's predictions as a "Law" goes beyond what Moore actually said. So it makes just as much sense (or just as little) to speak of the whole economic trend as "Moore's Law". After all, the fact that transitor logic keeps getting cheaper and cheaper isn't obvious to most people. The resulting collapse in the cost of computing and electronics is.
Creating bigger hard disks does nothing to solve the problem of reading data from existing storage devices. As time goes on our society stores more and more information without any real plan on how to ensure that the information we're collecting will be accessible in the future. Every year we lose more and more precious data to the deterioration of media as well as the loss of the equipment to read the remaining media.
I still say that levys against cds imply that I am a theif, and if I continue to pay the levys against cdrs, that I should be able to selectively download all the music I want, since I've paid for it anyways.
Oh well =)
Ever try and run NT4 on a 300 mhz system with ~only~ 64M ram? Runs pretty damn well.
Then add all the SP's and IE6, IT...SLOWS...TO...A...CRAWL...
fslg503-985-8686503-985-8686503-985-8686503-985-8
I'll be able to couple some hard drives to my flux capacitor and record the entire history of the universe.
Why is it no time traveller goes and says 'hi' to Jesus? Thats what I'd do.
The Kruger Dunning explains most post on
Consider the IBM XT 4.77MHz with a factory default formatted 17 sector per track MFM hard drive with a 6:1 interleave. The peak throughput of this machine was roughly 87 kilobytes per second.
... 3.06GHz, maybe a touch faster?
Now consider the new SATA machines with measured (not calculated) throughputs of 87 megabytes per second.
This is a 1,000x fold increase. For CPU processer throughput (speed) to keep up with this performance at the same rate, you would be able to buy a machine with a 4.77GHz CPU in it. Right now the fastest stock boxes are running what
CPUs have gotten faster. Hard drives have gotten faster faster.
Glonoinha the MebiByte Slayer
While it's nice that you took the time to rant about how much better of a programmer that you are then everyone else (the whole "If I didn't code it, it's crap" attitude really shines through), I think your scale is a bit off.
Lets say a library saves you a week. Now, lets say that like more people you use at least 4 libraries. Now, you've saved a month. A *month*, at which point you say you'll start to "consider" using external libraries. Well, I'm underpaid, but lets say you hired me to do this. By shaving a month off, you've saved over $3500 in my salary alone. And that's assuming that I (or anyone) could fully implement, *debug*, and "finish", a given complicated lib in 1 week. Great! Now, I quit, because I'm underpaid, and my replacement comes in. Now, I write good, well documented stuff, but it's not industry standard. So my replacement can't just sit down and pick up where I left off, but has to learn how *I* decided to implement libfoo. But it turns out that he's a lot like you, and thus 'he didn't write it, so it's crap'. And then *he* spends a month throwing away my stuff, and redoing it all. And on, and on, and on. There's a *reason* that things like Boost and Roguewave and Qt and Gtk and glib exist. And until you figure that out, you're doomed to be 1/10th as productive as you could be. Or, assuming that (as you claim) you've polished your libs to perfection and the productivity is there, I pity whomever has to take over your code. No, actually, I just pity you.
In general the problem is that while capacities have lept up, the rate at which we can read/write to those drives has not kept pace.
No, not really. The sustained transfer rate of HDDs has been steadily improving. It's obvious if you think about it. The drive stays the same size. The density goes up. The disc spins at the same rate or faster. Therefore, more data goes by the heads per unit time. This means trasfer rate will also increase. Specifically, this means that the transfer rate will scale linearly with the density of the disk.
What hasn't improved at the same rate as density is seek times. Seek times have always been the killer for mechanical storage mechanisms. They have to move something around and they have to obey Newton's laws.
In order for seek times to improve at the same rate as the rest of the drive impoves, we would need improvements in materials science and motor design which far exceeded those that increased density.
The other neat thing to think about is the spinning discs inside the HDD. Both those impovements I just mentioned might also allow you to spin the platters faster. This means that you could actually increase the transfer rate of your drive as well.
The immediate problem I can see is that moving something back and forth doesn't scale as nicely as storage density. Here's an example:
Say you've got something that you need to get from point A to B. Say you can do it in 1 microsecond. If you want to be able to do it in 1/2 microsecond, you need 4x more force. This means you need a motor with 4x more force, and a material that's 4x stiffer and 4x stronger.
Even if materials science, and motor designs were improving at a rate comparable to "Moore's Law", seek times wouldn't. Some things just don't scale the way we would like them to. Batteries are a good example.
Correction: You need a material that has 4x better strength to weight and stiffness to weight ratios.
It's also worth considering that you have to burn 4x more energy to move something from A to B twice as fast. Power dissipation in CPUs scales linearly with clock speed.
Life is too short to proofread.
I want holographic storage...mmmmm.... Holgraphic pr0n!! Allrighhhttt!!!
You know everytime the subject of hdd capacity/performance comes up I wonder why no one has produced a hdd with dual servo arms with the capacity to read/write to different sections of the disk simultaneously. More or less single disk raid 0. This would result in an incredible performance increase at a small price increase. Furthermore while raid 0 decreases storage system reliability a single disk with dual arms would actually be slightly more reliable than a standard disk; i.e. one arm fails you've got another one to keep going, (and I realize an arm failing isn't the primary cause of hdd failure). Maybe it would even be possible to optimize one arm for reading and one for writing.
I believe what has made code so bloated these days, is people believing it's more important to produce more faster and fix it later than do it right the first time.
I don't believe that I said anything about shipping broken code. Maybe I did. Maybe you could point out where. Or is your point (again!), that if you didn't write it, it can't possibly be Right(tm)?
And in your example nobody has saved $3500 on your salary alone. Every 3rd party lib you add for the sole purpose of saving time at the moment costs you about 10% when it comes time debug... you run into weird problems and can't trace them down.. why? because someone else wrote the code and now your learning THEIR code.
That 10% figure still stinks from where you pulled it out of. And if you don't think that taking a month off of a twelve month project is a *serious* gain, then I don't believe you have ever had to ship a working product.
Your app is guaranteed to be slower as well, a library that is designed to be more universal has to make sacrifices to that end.
Let's take your logic to its conclusion (without exagerating anything you've said). Your first premise is that general purpose libs are bloated and prone to error. The solution is to write your own versions, and then (as you said in the last paragraph of your first comment), you don't have to keep reinventing the wheel as you go on to other projects. Can I take that to mean that you reuse that code that you have polished? Code reuse is a good thing, I think we both agree. So, you have a lib that does something. You wrote it for app A, and then reuse it in app B. Of course, when reusing it in app B, you discover something that worked well at first, but needs to be more flexible now. So you change it a bit, and now it works equally fine in apps A and B (because you need to maintain A, that's a given). Now along comes app C, you make more changes AND WHAT THE HELL IS DIFFERENT BETWEEN YOUR LIBRARY AND ONE THAT OTHER PEOPLE WROTE??!??!!?!? You just managed to (as you so aptly put it) reinvent the wheel, making a generalized lib that can be reused but has only been 1)tested by you 2)understood by you 3)given a design review by you. How, *exactly*, is this magically faster/better/strong than something that's had people spending time optimizing it, had people looking at it from completely different angles to expose design flaws, and testing it in one thousand and one different situations, exposing bugs?
I'll give you a hint: it isn't. And the *only* reason for someone to continually and habitually refuse to use other people's libs like you've described, is pure and utter arrogance.
I'm going to bed...
At some stage the density may be high enough that you can store everything on a single cylinder and not need to move the head at all. That would also make the drives a bit cheaper to manufacture.
Of course I expect moving-head drives to still dominate because people would rather have a larger capacity, even if accessing most of that capacity requires a few milliseconds of seek time.
-- Ed Avis ed@membled.com