Slashdot Mirror
Can SSDs Be Used For Software Development?
hackingbear writes "I'm considering buying a current-generation SSD to replace my external hard disk drive for use in my day-to-day software development, especially to boost the IDE's performance. Size is not a great concern: 120GB is enough for me. Price is not much of a concern either, as my boss will pay. I do have concerns on the limitations of write cycles as well as write speeds. As I understand, the current SSDs overcome it by heuristically placing the writes randomly. That would be good enough for regular users, but in software development, one may have to update 10-30% of the source files from Subversion and recompile the whole project, several times a day. I wonder how SSDs will do in this usage pattern. What's your experience developing on SSDs?"
I'm using the Intel SSD and I think it's great - fast and silent. Will it last? I'd argue you never know about any particular model of hard drive or SSD until a few years after it is released. On the other hand, I'd also argue it doesn't matter much. Say one drive has a 3% failure rate in the 3rd year and another has a 6% rate. That's a huge difference percentage-wise (100% increase). And yet it's only a 3% extra risk - and, most importantly, you need a backup either way.
Math is hard! Lets buy both!
"His name was James Damore."
If they're good enough for Databases (frequent writes), they should be just fine for devel.
OTOH, You should be a lot more concerned about losing data because of a) software bugs or b) mechanical failures in a conventional drive
The Raven
If you're worried about losing work, I think your backup solution is what you need to improve instead.
The main difference is a good SSD is much, much faster than any hard drive. If discussions about the topic don't give that impression, it's only because people fixate on sustained transfer - where there is still some competition between slower SSDs and hard drives - rather than seek time, which is often more important, and where SSDs blow the doors off hard drives. To me, suddenly widening the biggest bottleneck in PC performance for the first time in a couple decades is pretty exciting.
You should get an SATA SSD instead.
Give me Classic Slashdot or give me death!
I use SSDs for my (both) development systems--the first was for the work system, and after seeing the improvements I decided I would never use spinning-platter technology again.
The biggest performance gains are in my IDE (IntelliJ). My "normal" sized projects tend to link to hundreds of megs of JAR files, and the IDE is constantly performing inspections to validate the code is correct. No matter how fast the processor, you quickly become IO-bound as the computer struggles to parse through tens of thousands of classes. After upgrading to SSD, I no longer find the IDE struggling to keep up.
I ended up going with SSD after reading this suggestion for increasing IDE performance. The general jist: the only way to improve the speed of your programming environment is to get rid of your file access latency.
If you're not good enough at arithmetic to understand that this isn't an issue, should you really be developing software?
Maybe you can explain why it isn't an issue, then?
One thing about flash in general is that in order to rewrite a small amount of data, you need to (at the low level) erase and rewrite a relatively large amount of data. So depending on how extensively the filesystem is cached, where the files are located, etc., rebuilding a medium-sized project could wind up re-writing a large portion of the SSD...
Bow-ties are cool.
If you give your programmers an 8-way 4GHz m/b with 64GB of memory (if sucha thing exists yet), they'll use all the processing power in dumb, inefficient algorithms, just because the development time is reduced. While those of us in the real world have to get by on "normal" machines.
When we complain about poor performance, they just shrug and say "well it works fine on my nuclear-powered, warp-10, so-fast-it-can-travel-back-in-time" machine"
However, if they were made to develop the software on boxes that met the minimum recommended spec. for their operating system, they'd have to give some thought to making the code run efficiently. If it extended the development time and reduced the frequency of updates, well that wouldn't be a bad thing either.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Unless you type like The Flash, even MLC SSDs from the better vendors (Intel) should be fine for anything outside of server applications. Simple math should back this up (how many GB total the drive can write over its lifetime vs how much you produce each day).
I don't know who this "The Flash" is... But this reminds me of some odd invoices I've seen here lately at Star Labs. Someone special-ordered a custom keyboard rated to one hundred times the usual keystroke impact, an 80MHz keyboard controller, and a built-in 1MiB keystroke buffer. Pretty ridiculous, huh? The usual 10ms polling rate for a USB keyboard should be enough for anybody - no need for all that fancy junk.
Bow-ties are cool.
Current SSDs have a lifetime of somewhere around 10.000 years. I think that's enough.
10000 years or 100000 writes, whichever comes first. :D
Bow-ties are cool.
Just got one in a Dell laptop, came with Ubuntu. A subjective overview:
I have no idea how well it performs with swap. I'm not even really sure why I have swap -- I don't have quite enough to suspend properly, but I also never seem to run out of my 4 gigs of RAM.
It's true, the write speed is slower. However, I also frequently transfer files over gigabit, and the bottleneck is not my SSD, it's this cheap Netgear switch, or possibly SSH -- I get about 30 megabytes per second either way.
So, is there gigabit between you and the SVN server? If so, you might run into speed issues. Maybe. Probably not.
Also worth mentioning: Pick a good filesystem if a lot of small files equals a lot of writes for you. A good example of this would be ReiserFS' tail packing -- make whatever "killer FS" jokes you like, it really isn't a bad filesystem. But any decent filesystem should at least be trying to pack writes together, and I only expect the situation to improve as filesystems are tuned with SSDs in mind.
It also boots noticeably faster than my last machine. This one is 2.5 ghz with 4 gigs of RAM; last one was 2.4 ghz with 2 gigs, so not much of a difference there. It becomes more obvious with actual use, like launching Firefox -- it's honestly hard to tell whether or not I've launched it before (and thus, it's already cached in my massive RAM) -- it's just as fast from a cold boot. The same is true of most things -- for another test, I just launched OpenOffice.org for the first time this boot, and it took about three seconds.
It's possible I've been out of the loop, and OO.o really has improved that much since I last used it, but that does look impressive to me.
Probably the biggest advantage is durability -- no moving parts to be jostled -- and silence. To see that in action, just pick out a passively-cooled netbook -- the thing makes absolutely no discernible noise once it's on, other than out of the speakers.
All around, I don't see much of a disadvantage. However, it may not be as much of an advantage as you expect. Quite a lot of things will now be CPU-bound, and there are even the annoying bits which seem to be wallclock-bound.
Don't thank God, thank a doctor!
Neither he nor you have attempted to answer the question quantitatively. Look at how big a block is, a bit about their write-leveling strategy, how large your source files are, the quantity of data you overwrite and how frequently, and what the lifetime of SSD blocks is, and figure out how long the SSD should last. Even an order-of-magnitude calculation would be better than nothing.
You both are approaching the problem qualitatively: SSDs have limited rewrite lifetimes, and I'm doing a lot of rewriting -- isn't that bad? You don't know! Figure it out!
Now find a hard disk that'll last that long.
extern warranty;
main()
{
(void)warranty;
}
The best bet if your project is smaller than about 20GB is to buy a box full of ram and use a FAT32 formatted ramdrive. Orders of magnitude faster than even an SSD.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Before we start, let me make a prediction: You never asked about the MTBF of your hard disk, right...?
http://www.intel.com/design/flash/NAND/mainstream/
a) When Intel says "new level of ... reliability", maybe it means they thought about this problem when they designed the drive.
b) When they say "NAND flash", maybe it means they're not using the cheapest MLC memory as mentioned in that scary wikipedia article.
c) When their datasheet says "Minimum useful life of five years, assuming 20Gb/day of writing", maybe they got those numbers from real engineers, with degrees.
d) When their datasheet also says, "Should the host system attempt to exceed 20 GB writes per day by a large margin for an extended period, the drive will enable the endurance management feature to adjust write performance, this feature enables the device to have, at a minimum, a five year useful life", maybe they were really really paranoid about saying 'five years' because they know people will start class-action lawsuits if it doesn't work out.
So, um, how this even got greenlighted in 2009 is beyond me. It's like 1999 called wanting its flash-myths thread back.
No sig today...
The English language has syntax, too. It concerns things like proper placement and use of apostrophes.
Cheaper drives (which mgmt is sure to require) have 1,000 write cycles (assuming the worst). For certain high-traffic files, that means (assuming 30 writes in a day) a whole 33 days of use.
If that were true. Then an SSD hard drive couldn't run a linux mail server for a small business for more than a couple minutes thanks to the various log files.
1) The maximum write cycles for a block was around 10,000 in 1994. And about 100,000 in 1997. But in 2009 you think 1000? No. Its currently in the millions, even for the cheap SSDs.
2) Look up wear levelling.
3) Look up the MTBF on an SSD vs a spinning platters type.
I've seen studies that have calculated that modern drives will could write continuously at maximum speed for 50+ years before exhausting wear levelling and hitting write cycle limits.
The odds of it failing from something else long before then are much greater. Getting a mere 5+ years of life and easily beating your average spinning disk hard drive is a no brainer.
This is why it's almost pointless to ask a question on Slashdot. You get 100s of replies in a 50/50 distribution of random tech-word ramblings and flat out useless contempt, leaving you feeling stupid and your question unanswered.
NTFS has a fairly high overhead for a compile, lots of small temp files that all have to be created and deleted having their ACL's added to the MFT and then removed. I've seen compile time drop to 1/4th the time by switching from NTFS to FAT32 on the same hardware.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
The whole "millions" thing may be true for SLC parts. MLC parts (which are much cheaper) have much lower write counts. The best MLC flash I'm aware of is only rated for a million write cycles. Thousands or tens of thousands is more typical for MLC flash parts. Write amplification makes this even more fun, since it means that a write of one disk block can require rewriting many, many blocks that otherwise would not have been written. If the wear leveling algorithm is optimal, then it's a moot point. If the wear leveling is nowhere near optimal, you can create artificial workloads that will burn out a few cells on the flash part in hours, which is a bit problematic. There is no clear-cut answer for this sort of question, unfortunately, at least not with the current crop of MLC tech.
Consider a log-structured filesystem, perhaps....
Check out my sci-fi/humor trilogy at PatriotsBooks.
If you build is really IOPS-bound, then an SSD will utterly smoke a single disk. Even a whopping great expensive disk can only muster 300 iops under the best possible circumstances, and typically 100 iops under real conditions. A cheapo SSD can deliver 1000 mixed iops, and a good SSD can deliver 100,000 mixed iops. Ever since switching to an SSD on my dev machine I no longer have to suffer through things like a :wq in vim taking 5-10 seconds, or loading a file taking several seconds, etc. One of the benchmarks I did was starting Firefox during a build. On the machine with a disk, it actually took more than ONE MINUTE to start Firefox under a build load. With the SSD, there is no measurable difference between the Firefox startup on an idle machine and a machine with a build happening. The difference is massive.
Or using Java/Haskell/Ruby and/or Eclipse/VS.NET/Emacs (delete according to prejudice).