High speed M.2 SSDs and CPU speed (limitations)?

Reizla

This is prolly one for @Quizzical ...

I'm developing a RPG with a huge open-world map and I need 10.000s of small HDD r/w instructions to get the map created. Right now I'm using a conventional HDD and processing a piece of 300x300m takes about 3 minutes. Because of this I'm on the fence to grab a SSD to speed up the process, but am not sure what to get. Should I get a regular SSD or a M.2 (with controller since my mobo doesn't support them) to speed up the whole process.

I've looked at the Samsung SSDs whith ~500Mpbs read/write speed but I've also seen M.2s with up to 3200/2400Mbps read/write speed. I know that the 'regular' SSD will be no problem for my system, but what about the high speed M.2 (with controller)?
My CPU is an AMD FX-8350 non-OC on an AsRock 990FX Extrme3 mobo along with 32Gb DDR3-1600 RAM. I've seen PCI(e) M.2 controllers that should be able to support that 3200/2400 M.2 SSD in my system, but what about the speed and/or slowdown in it - are my CPU fast and the mobo's controllers fast enough to support this kind of speed?

Aside from that, it the double price of the M.2 with controller worth the double price of the regular SSD when comparing performance? If the Samsung is about 10x the speed of my current HDD, that'd mean that instead of 3 minutes the tast is done in ~20 seconds (which I think is already a huge improvement) while the M.2 would be doing it in about ~4 seconds.

Any input/thoughts are welcome!

Cleffy

I wouldn't get an M.2 drive with your system. It makes a difference, but not a big enough reason to pay double on the same capacity and an additional piece of hardware for the PCI-e slot since your board doesn't have an M.2 slot.
If you were building a new system from scratch, then I would think about it.

Renoaku

Also depends on motherboard "Certain Boards" using a M.2 Slot will disable some of the other SATA ports, generally not worthit IMO unless you don't need a lot of drives.

Vrika

I think you should be looking for random read/write performance instead of bandwidth for something that does a huge number of small read/write operations. Max bandwidth is really only used when the hard disk gets to transfer sequential data.

I agree with Cleffy that it's not worth it to buy M.2. SSD and a separate controller. If you're on a budget just get SSD, if you're not get a completely new computer for your work.



If the amount of data is small enough you might also consider setting up a ramdisk, that would exceed the speed of any SSD.

Ridelynn

Don't overthink it too much.

RAM Disk isn't a bad idea for static data that is retained/backed up elsewhere -- so if/when your machine does crash you can just reload the RAM disk from the SVN or whatever your using.

Apart from that, any SSD is better than no SSD. If your motherboard doesn't have M.2 - then don't sweat it, get a Sata3. Don't sweat the specs too much - just get something affordable and name brand. Especially if you are R/W from a lot of small files, the difference, even with the worst (working) modern generation SSD you could possibly buy today is going to be significantly faster than 10x your current HDD. It's all about the Random I/O score, not sequential transfer speed.

I've put SSDs into machines with pretty poor CPUs - dual core Athlon laptops running at something like 1.5Ghz, for example. They go from 5 minute power off to desktop ready boots to about 25 seconds. It's very significant.

Quizzical

How much do you need to read and write from disk over the course of making your map?  Because if you need to write out 10 GB and then read it all back in, even a SATA SSD can do that in 40 seconds.  If you're looking at 1 GB, then that would be 4 seconds on a SATA SSD.

If small file IOPS was the problem, not sequential throughput, then SATA SSDs commonly have somewhere in the ballpark of 100k small random read/write IOPS, making it plausible that you could have all of the I/O for your maps done in under a second.

It depends greatly on the details of your code, but I suspect that with any modern SSD, either the SSD would be fast enough that you were waiting on CPU work to generate the map, or else the whole thing would be done in a few seconds.  If the former, there wouldn't be any gains to be had from a PCI Express SSD, and if the latter, the gains would be small.

centkin

You could also look at (improving the) compression of the data.  Consider also the lifespan of an SSD drive.  Regardless I'd be in raid 1 if the data is important.

Reizla

Thanks all for the input. I've ordered a regular (520Mbps r/w) SSD at my local PC store. He also advices against using a M.2 drive with adapter because the PCI(e) interface would not get the max out of it by a long shot and that little extra speed over a normal SSD is not worth the extra money (I appreciate this guy for his honesty and that's why I always buy at his store).

Quizzical said:

How much do you need to read and write from disk over the course of making your map?  Because if you need to write out 10 GB and then read it all back in, even a SATA SSD can do that in 40 seconds.  If you're looking at 1 GB, then that would be 4 seconds on a SATA SSD.

If small file IOPS was the problem, not sequential throughput, then SATA SSDs commonly have somewhere in the ballpark of 100k small random read/write IOPS, making it plausible that you could have all of the I/O for your maps done in under a second.

Total size to read/write for one map (around 500 objects) is only a couple of MBs total. Problem is that at this state of development I already have 12 of these maps and I expect that I'd end up with 100+ maps, if not 500+...

Quizzical said:

It depends greatly on the details of your code, but I suspect that with any modern SSD, either the SSD would be fast enough that you were waiting on CPU work to generate the map, or else the whole thing would be done in a few seconds.  If the former, there wouldn't be any gains to be had from a PCI Express SSD, and if the latter, the gains would be small.

The CPU is certainly not the problem. When running on the conventional HDD the CPU doesn't go over 25% performance. As for the code, sadly I can't do a lot on that because these are small Unity3D editor scripts where I can't optimize a lot.

centkin said:

You could also look at (improving the) compression of the data.  Consider also the lifespan of an SSD drive.  Regardless I'd be in raid 1 if the data is important.

Nothing to compress because of the nature of the files. These are Unity3D prefabs that i need to work on before I can even compile the stuff and then optimize/compress (which Unity3D does mostly by itself.Ridelynn said:

Don't overthink it too much.

RAM Disk isn't a bad idea for static data that is retained/backed up elsewhere -- so if/when your machine does crash you can just reload the RAM disk from the SVN or whatever your using.

I've put SSDs into machines with pretty poor CPUs - dual core Athlon laptops running at something like 1.5Ghz, for example. They go from 5 minute power off to desktop ready boots to about 25 seconds. It's very significant.

Was considering a RAM Disk as well, but I've already crashed the PC once when Unity3D came over the 32Gb RAM threshold that my PC has installed (somehow it didn't start swapping at all to the HDD). With that, what's the SVN you're talking about..?

As for boot - I don't really care how fast my PC boots, though I gotta say that about 25-30 seconds with a HDD and Windows 7 isn't too bad IMO. Guess it's because I have Windows installed on it's own HDD and am using a 2nd HDD for development and those few games I still play on my PC.

Quizzical

The I/O for a SATA SSD is going to be basically trivial, and could be done within a few seconds even with 500 maps.

As for a CPU bottleneck, you might not have one now, but you probably will once you get the SSD.  If the I/O would be two minutes with a hard drive or three seconds with an SSD, but there's thirty seconds of CPU work, then the whole run will take about two minutes with a hard drive or thirty seconds with an SSD.

As for SVN, you do have some sort of version control or at least backup, I hope.  If you don't, you'll learn soon enough why you should have--after the lack of it kills your project.

Ridelynn

SVN is a particular package of software version control - open source from Apache. I use it loosely to describe the entire genre. Git and SVN are probably the most popular, there are several other packages that accomplish the same thing.

Software version control serves as a repository and archival system - code gets checked out - while a developer has it checked out, other people can't alter the same code until that developer checks it back in. When you go to compile, the SVN will always use the latest checked in version of all files for the compile and run.

Old versions of files that are checked in are kept on the server, making it easy to roll back to previous editions. You can see who submitted what edits to what files, and when.

Other folks can "fork" the code - letting you have duplicate paths for R&D, etc., with the caveat that too many forks can become obviously difficult to manage, especially if you are looking to merge them back together sometime in the future.

It helps particularly with multiple developers - you won't be stepping on each other's toes. Two coders can't be working on the same file at the same time and release contradictory edits. It also helps to enforce good code habits - common sense splitting of files, of libraries, of headers, etc. that helps keep your code clean and manageable.

And it's nice for just archival purposes. If a bug crops up,  it's much easier to trace when and where (and who) it came from, making it easier to correct, or at the very least, roll back. 

With respect to the RAMDisk - if (when) your PC crashes, you obviously lose the RAMDisk. But you would just recopy the data over to there after the reboot from your SVN - very nice if you want to have rapid R/W access and are doing a lot of small changes of major files stored on your HDD, but your recompile and/or run needs to access a lot of other data that is relatively static, such as graphics assets or precompiled shader maps. Your IO time is nil, with the obvious drawback that it does take some time to recopy the data between reboots.

Your crash wouldn't have been because the HDD/VRam didn't spool out fast enough - Windows handles all of that pretty well and can accommodate some ridiculously large memory sizes -- something like 128GB of physical memory and 256TB of total memory on the 64-bit edition of Windows 7.

Your system crash would be an unhandled exception somewhere, which is extremely common in development as you find pointers that aren't handled correctly, memory that doesn't get cleaned up on exit, pass by reference versus pass by value, etc., and not exactly unheard of in drivers and development software or even a flaw in hardware somewhere -- so not blaming it all on your code, could very well be a bug in a driver or Unity... but it's probably your code.

With respect to boot times - most people don't really care what their boot times are, as most systems just sleep or hibernate anymore between short breaks, and actual boots are fairly rare, maybe a couple of times a day. What boot time is good for, however, is a good indication of how well your I/O system handles multiple small file accesses - as the boot process for virtually all modern operating systems involves accessing thousands, if not tens of thousands, of very small files in rapid succession.

Cleffy

Ohh I totally forgot about Ram Disks. If your data is under 8GB and it's just temporary information, then use a ram disk. That's what ram was made for, a bunch of random read writes.