PC for software development - recommendations please!

[SiliconWizard]

Nevertheless, my next desktop/HPC machine will have dual SSD for storage; partially RAID-[01].  I have some very large continuous datasets (hundreds of megabytes) that I'd like to see how fast I can chew trough, mostly MD simulations and such; I'm really looking forward to 1GB/s+ transfer rate for those...

A reasonably good single NVMe SSD on PCIe 4.0 will give you close to 7GB/s. And on PCIe 3.0 about half of that. Of course on large transfers, not small random blocks.

[Nominal Animal]

Nevertheless, my next desktop/HPC machine will have dual SSD for storage; partially RAID-[01].  I have some very large continuous datasets (hundreds of megabytes) that I'd like to see how fast I can chew trough, mostly MD simulations and such; I'm really looking forward to 1GB/s+ transfer rate for those...

A reasonably good single NVMe SSD on PCIe 4.0 will give you close to 7GB/s. And on PCIe 3.0 about half of that. Of course on large transfers, not small random blocks.

I dropped a zero there, I think! 

My current SSD, Samsung PM961, maxes out at 3 GB/s.  I've been looking at the Samsung 980 Pro series, which also has about 3x the 4k random read rate than PM961, which should help in compiling things.  (I am aware of the 3B2QGXA7 firmware being a big problem.)
It'd also be very interesting to see if RAID-1/mirroring still helps in random small file read cases in Linux, like compiling stuff.

[SiliconWizard]

Nevertheless, my next desktop/HPC machine will have dual SSD for storage; partially RAID-[01].  I have some very large continuous datasets (hundreds of megabytes) that I'd like to see how fast I can chew trough, mostly MD simulations and such; I'm really looking forward to 1GB/s+ transfer rate for those...

A reasonably good single NVMe SSD on PCIe 4.0 will give you close to 7GB/s. And on PCIe 3.0 about half of that. Of course on large transfers, not small random blocks.

I dropped a zero there, I think! 

Ha, then sure!

It'd also be very interesting to see if RAID-1/mirroring still helps in random small file read cases in Linux, like compiling stuff.

I'd be curious to see that. How could RAID-1 achieve that?

[Nominal Animal]

It'd also be very interesting to see if RAID-1/mirroring still helps in random small file read cases in Linux, like compiling stuff.

I'd be curious to see that. How could RAID-1 achieve that?

On software RAID-1, the kernel does a read on only one drive, not both.  Remember, there is no compare on reads.  Although writes must be duplicated on both drives, reads only access one of the drives, so as long as the workload is mostly reading small files and the I/O scheduler is smart enough to read from both drives, the overall small file random 4k-reads-per-sec increases.  In theory, it doubles.

[SiliconWizard]

so as long as the workload is mostly reading small files and the I/O scheduler is smart enough to read from both drives,

That's the part I had no idea about. Does it actually do this?

[paulca]

3D Mark uses semi-sythetic real world loads to benchmark disks.

Here's mine from this morning:
https://www.3dmark.com/3dm/95229506?

That is a PCI-E Gen 4 Mv.2 drive on a Crosshair Hero 8

[nigelwright7557]

I'm inclined to believe the people saying that storage doesn't make much difference in typical build times, although SSD helps a lot with other things like git.

My PC boots in half the time with a M.2 SSD.
I have a 12600k, 20GB DRAM and it compiles hundreds of thousands of lines of code in a couple of seconds.

[brucehoult]

I'm inclined to believe the people saying that storage doesn't make much difference in typical build times, although SSD helps a lot with other things like git.

My PC boots in half the time with a M.2 SSD.
I have a 12600k, 20GB DRAM and it compiles hundreds of thousands of lines of code in a couple of seconds.

Sure, but once we got rid of Classic MacOS and Windows 95/98 we boot PCs once every couple of months, so who cares about boot times?

[Nominal Animal]

so as long as the workload is mostly reading small files and the I/O scheduler is smart enough to read from both drives,

That's the part I had no idea about. Does it actually do this?

Used to, on spinny rust drives over a decade ago, when seek times were measured in milliseconds.  Haven't tested it since.

[paulca]

Sure, but once we got rid of Classic MacOS and Windows 95/98 we boot PCs once every couple of months, so who cares about boot times?

Yep.  Right up until the tripled the cost of electric here.

Then all (4 PCs) those 5-10W of sleep power had to go.  They now all get shut down.  Except the linux server.

At the moment, it takes my monitors longer to wake up to the new signal than it does for windows to boot.  I might see BIOS, then the monitor goes into it's black screen while EUFI enables the framebuffer to show the spinner screen with windows logo, however I rarely see it because the PC boots to the login screen faster than the monitor reconnects to the framebuffer.... especially as windows resets it again before displaying the login screen.

[SiliconWizard]

It does make a significant difference for build times, obviously it depends on the exact thing you're building.
Large C++ files, for instance, tend to take a long compile time and in this case, file access time will only be a moderate factor.

For those using KiCad, this is a very easy to witness improvement, when opening the symbol and footprint editors for the first time in a session (so nothing cached yet.) Libraries have a ton of small files.
Opening the symbol editor (first time) when libraries are on a HDD (even the fastest one) will take up to 20s-30s. Yes, drives you nuts. On a SATA SSD, it will typically be around 5s.
On a NVMe SSD (which I have switched to for KiCad libraries now), it's almost instant. Makes a freaking great difference when you use KiCad a lot.