Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
High speed M.2 SSDs and CPU speed (limitations)?
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!
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!
Comments
If you were building a new system from scratch, then I would think about it.
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.
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.
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.
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+...
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.
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: 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.
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.
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.