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?"

Comments

I'm not seating it

[timeOday]

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.

Re:I'm not seating it

[Haeleth]

"Anecdotal evidence" is an oxymoron.

Point is, I could just as easily claim that SSDs last ten years, and since neither of us has provided a shred of evidence to support our assertions, neither of us has any credibility whatsoever.

Get an enterprise drive (SLC, not MLC)

[vlad_petric]

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

Re:Umm...

[Tetsujin]

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...

Developers should use *slow* machines

[petes_PoV]

That way it'll encourage them to write efficient implementations.

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.

Re:Developers should use *slow* machines

[Anonymous Coward]

compile time has nothing to do with inefficient algorithms slowing down programs.

Re:Developers should use *slow* machines

[vadim_t]

Disagree. This problem went away for the most part.

First, performance isn't nearly the problem it used to be. We aren't using anymore the kind of hardware that needs the programmer to squeeze every last drop of performance out of it. In fact, we can afford to be massively wasteful by using languages like Perl and Python, and still get things done, because for most things, the CPU is more than fast enough.

Second, we're not coding as much in C anymore. In C I could see this argument, lazy programmer writing bubble sort or something dumb like that because for him waiting half a second on his hardware isn't such a problem. But most of this has been abstracted these days. Libraries, and high level languages contain highly optimized algorithms for sorting, searching and hashes. It's a rare need to have to code your own implementation of a basic data structure.

Third, the CPU is rarely the problem anymore, I/O is. Programs spend most of their time waiting for user input, the database, the network, or in rare cases, the hard disk. A lot of code written today is shinier versions of things written 20 years ago, and which would run perfectly fine on a 486. Also for web software the performance of the client is mostly meaningless, since heavy lifting is server-side.

Also, programming has a much higher resource requirement than running the result. People code on 8GB boxes because they want to: run the IDE, the application, the build process with make -j4, and multiple VMs for testing. On Windows you're going to want to test your app on XP and Vista, on Linux you may need to try multiple distributions. VMs are also extremely desirable for testing installers, as it's easy to forget to include necessary files.

I'd say that giving your developer a 32 core box would actually be an extremely good idea, because the multicore CPUs have massively caught on, but applications capable of taking advantage of them are few. Since coding threaded code is not lazy but actually takes effort, giving the programmers reasons to write it sounds like a very good idea to me.

Re:Developers should use *slow* machines

[glwtta]

That way it'll encourage them to write efficient implementations.

That's just stupid - I'm going to write better code because my compiles take longer?

There seem to be a lot of these posts on Slashdot with down-home folk wisdom on how to educate the smug and indifferent programmer, who is so clearly divorced from reality that he doesn't even know what computers his customers use. I get the sneaking suspicion that the authors know very little about actual programming.

There are two reasons for bad software:

a) incompetent programmers
b) bad project management

The latter includes things like unrealistic timelines and ill defined scope and requirements. I'm not sure which one is the bigger culprit, but both are pervasive.

In neither case, though, are you going to fix the problem with gimmicky bullshit like inadequate equipment.

Re:Developers should use *slow* machines

[psnyder]

A similar argument was used in World War II to keep bolt action sniper rifles in use in some countries instead of 'upgrading' to 'auto-loading' rifles. With bolt action, after shooting, you had to physically lift the bolt, cock it in place, and push it down again before you could fire another shot.

The argument was, if the snipers knew they couldn't fire again immediately, they would be more careful lining up and aiming that first shot. With an 'auto-loading' rifle, you could keep your eye in the scope and fire off more rounds.

It seems quite obvious, that if you're in the field, the seconds after that first shot are very important. If you need to take your eye away from the scope, and spend the time reloading the chamber, the outcome could be completely different than if you were able to fire off a few rounds immediately.

A good sniper would have aimed that first shot up carefully no matter what rifle they were using, in the same way a good programmer will make efficient, elegant algorithms no matter what machine they're using. You'd only have to 'limit' your programmers if you think they're bad programmers. If a supervisor is thinking along these lines, they've already hired bad programmers and are setting both themselves and their team up for failure. The faster the machines, the less time wasted. You don't need forced limits reminding them about efficiency, because any decent programmer will already be thinking about it.

Re:Developers should use *slow* machines

[merreborn]

Developers should use *slow* machines
That way it'll encourage them to write efficient implementations.
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.

No, developers should develop on fast machines... and test on slow machines.

It's a waste of money to pay your programmers $50/hr to sit and wait for compiles to complete, IDEs to load, etc. That hurts the employer, and the additional cost gets passed on to the customer. It's in everyone's best interest that developers are maximally productive.

Give them fast development environments, and realistic test environments.

Re:Umm...

[blueg3]

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!

Simple arithmetics

[MathFox]

A typical flash cell easily lasts 10.000 writes. Let's assume that every compile (or svn update) only touches 10% of your SSD space, that gives you 100.000 "cou" (compiles or updates). If you do 20 cou per day, the SDD will last 5000 working days, or 20 year.

Now find a hard disk that'll last that long.

Re:Swap?

[afidel]

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.

Re:Umm...

[bluesk1d]

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.