28 September 2008

Solid State Drives won't speed up your compiles

NOTE: This was written in 2008. SSD hardware is better now...

(If you don't want to see off-topic stuff like this then use the on-topic filter.)

(Since this was written, affordable SSD tech has improved a lot, so it may no longer be true.)

I bought one of the new SATA2 solid state drives (SSD) in the hope that it would speed up compilation of the project I'm working on. The project is a large and complex financial system. I've been given quite a powerful machine (quad core Xeon, four gig of RAM) to work with but compiling the beast still takes about 1.5 hours.

With the normal HDD I heard a lot of disk thrashing. By default Visual Studio was compiling four projects in parallel (one per CPU) and it seemed to build faster (or at least no slower) if reduced that to two. I thought that the HDD's seek time may be a bottleneck when those parallel compilers/linkers were writing so much data in parallel. SSDs have great seek times so I ordered one to see if it would speed things up.

It didn't. At least not this particular SSD (a new model which only just came out), with the particular project I'm working on and the hardware it was combined with. It didn't make things any better or worse. I tried moving the temp directory to the SSD as well (since Visual Studio writes a lot of data to TEMP) but that made no difference either.

I took the SSD home and tried it with some of my Opus-related projects (plugins etc.) in case it fared better with different hardware. The SSD seemed faster in my home machine than my work machine, probably due to a better SATA2 controller (or maybe a less imposing real-time anti-virus scanner?), but it made no difference to compilation times compared to my existing HDDs. (That said, I've got quite fast HDDs.)

I've got no benchmarks to show because it never made any difference whether the SSD was used or not.

I'm just posting this to warn people not to waste money on an SSD if the aim is to speed things up. You'll get better value out of a fast HDD.

I've heard that some SSDs don't even use less power than laptop HDDs, on average. (Since they don't have a low-power state they are always on. HDDs use more power when active but when they are inactive they use less. So, if what I read was correct, HDDs use less power on average unless you are reading/writing a lot of data.)

This isn't to say that SSDs are useless. They're silent and don't produce heat (which means less fan noise and less power spent on spinning fans). The one I have seems about as fast as an HDD, too, and it's probably difficult to get 2.5" HDDs at this kind of speed. I'd like one in my laptop. (Sadly, my laptop only takes PATA drives so I can't put the SDD I bought into it.) Just don't buy an SSD thinking that the improved seek times will benefit your desktop because chances are they won't.

EDIT:

It's an OCZ Core Series V2 drive. They've only just come out this month (yes, just a few months after the previous generation) and I failed to find reviews that compare them to other drives, or the older Core Series ones. Maybe other types of SSD are better. A friend posted me an interesting article showing that the OCZ Core Series (not V2) and some other SSD models had some big problems due to the controller chip they used but I don't know if the V2 uses the same chip or corrects those problems.

Someone also said that compilation isn't disk intensive so the whole idea was stupid... Uh, it can be disk intensive and seek intensive, especially with the amount of data both written and read by four huge debug builds running in parallel. (Large PDB and SBR files are read and written. Large binaries, too, and all the header files, source files and lib files have to be read, of course.) (It can also be memory and CPU intensive. Where the bottleneck is will depend on the project and other hardware.)

7 comments:

Goran Mitrovic said...

Even in benchmarks, SSD disks aren't faster than normal drives. If I were you, I'd make a RAID out of 2-3 classic hard drives and put another 4-8gb of RAM (they would be used as disk cache).

Also, turn off generation of sbr files; they can double compilation time.

Leo said...

Doesn't that depend on what's being benchmarked?

I figured it was worth a try due to the disk thrashing going on reading/writing all that data when doing 4 compiles at once but, of course, either that was wrong or some other aspect of the SSD compensated and meant there was no real advantage.

(Actually, the SSD did seem to improve things when doing 4 compiles at once, I think, but I didn't test enough to be totally sure. Either way it wasn't faster than doing just 2 compiles in parallel (thus thrashing the disk less) with the old HDDs.)

RAID doesn't seem worth the hassle to me as it'd require messing with the system drive which I don't want to do on my work machine. (If anything goes wrong it'll be at least a week before support come and put the rebuilt machine back on the LAN. I've been there when XP SP2 trashed my PC!) (Or I'd have to find some extra HDDs and leave the system drive alone.)

Adding more RAM probably won't do any good as it's a 32-bit XP machine. I don't think 64-bit XP is used/supported at work.

(At home I don't compile anything big enough to care about speeding things up. 5 minute compiles tops, compared to the monsterous 1.5 hour compile at work!)

Leo said...

Oh yeah, turning off SBR files would speed up compilation but very much slow down development.

Goran Mitrovic said...

I use VAssist, so, sbr files are redundant.

Anonymous said...

I'll give a recommendation for eBoostr under XP. It literally cut down my compile times on a large project by more than half (and that was with a raptor 10Krpm drive and a RAID). For me it was a cheap, easy and very effective upgrade. (more so than the 10krpm drive ended up being). You might need to give it a couple days to pick the right files to pre-cache, but you can check the contents of the cache with it's built in viewer and manually rebuild the cache. YMMV.

Anonymous said...

This is a bit of a crazy commentary, leo - absolutely no disrespect intended. There's no documentation to back up your claims so nobody can tell if there are "hidden" problems impacting your overall performance.

My Alienware M15x notebook came with a (cheaper) Samsung SSD drive (128GB) and it flies! I'm getting read/write speeds of well over 200MB's per second and just under 150MB's per second respectively (CrystalDiskMark). It's out-performing any hard drive I've ever had - and it's a lower end SSD.

I'm about to install an Intel X25-M 80GB drive that's proven to be even faster!

Based on your comments, I can almost guarantee that either something is wrong with your system settings (or other variables) or your expectations weren't properly aligned going in.

Is/Are your partition(s) properly aligned based on your OS and drive specifications? This item alone can negatively impact the performance of your SSD by nearly 50%!

Is the application itself creating a bottleneck that makes it appear the SSD is at fault?

There are many, many other questions to ask but I'd encourage you to continue researching and reading up on how to properly utilize this "new" technology. Rotational disks will soon be a thing of the past!

Leo said...

I did not say that SSD drives were slow.

I said that SSD drives -- or at least the one drive I had -- at the time (which was a couple of years ago now) did not speed up *one particular type of task*, and thus people should beware if they were thinking of buying one *for that task* without doing further research.

If you think that's wrong, have you done your own SSD vs HDD tests compiling large projects in Visual Studio to confirm it? By the sound of it you've not used the same machine with two types of drive at all. :-)

An SSD could well make a difference with compilation when using better and/or more modern drives. (Or even when compiling different projects.) I don't actually know as I have not re-tested. However, you cannot assume that just because an SSD is fast at some things it will make a big difference to everything. That was the mistake I made -- as well as buying a rubbish SSD! -- and what I wanted to warn people about.

Benchmarks would have been pointless at the time. The compilation took about 2 hours with or without the SSD.

I have a (much newer, better) SSD in my current machine as the system drive, as it happens. I'm not against the technology and it has improved a hell of a lot in the last couple of years.

At the time I wrote this, I think you had to spend a ridiculous amount on one of the Intel SSDs if you wanted one that wasn't terrible. Now Intel have cheaper models and several other manufacturers also have good, inexpensive models. This was not the case at the time I wrote the post. Whether that translates into any difference when compiling, I don't know. I'm no longer working on that project which took 2 hours to compile so it's no longer an issue.

(The project had no relationship with Opus, by the way. :))