M.2 gen3 x4

[firebug11]

Can anyone in my with a Asrock Z170M Extreme4 and a samsung 950 256gb in the m.2 slot tell me there boot time?
Or anyone with knowledge on the subject tell me if it is actually worth the money,

The board comes with 6 sata connections and when using the m.2 disables the first 2 sats connections, this leads me to believe that it wont use any pci-e connections from my graphics card?

 

[Hlsgsz]

Not worth it. You would get a 1 sec max boot time reduction versus a 2.5" SATA SSD but pay twice for the same capacity. And the difference in real world usage is marginal to indiscernable.
It's best to get the largest capacity SSD you can afford. I would recommend the 512GB Samsung 850 EVO.
Look at it this way, do you prefer a 1 sec boot time reduction and then to sit through long loading times in games that don't fit on your SSD, or would you rather have all your games and software be snappy?
Don't get me wrong, NVMe is the future, but it needs to fall in price considerably to be worth touching. Also, software needs to catch up and learn how to take advantage of the proprieties of such SSDs, and that is just not the case yet(or will be for some time).

 

[InvalidError]

Most software needs to process data after loading it. Once you have enough SSD bandwidth to keep whatever core(s) are responsible for handling the data, the extra bandwidth beyond that becomes entirely hypothetical.

The first time I start GIMP from my HDD, it takes 12 seconds to load. If I close and re-open it so it can reload from the file system cache which has a bandwidth of over 5GB/s (25X faster than my HDD with practically zero latency), GIMP still takes three seconds to load due to all of the processing it does while loading stuff. That's only a 4X speed-up between HDD and best-case/SSD for this example.

 

[Hlsgsz]

Most software needs to process data after loading it. Once you have enough SSD bandwidth to keep whatever core(s) are responsible for handling the data, the extra bandwidth beyond that becomes entirely hypothetical.

The first time I start GIMP from my HDD, it takes 12 seconds to load. If I close and re-open it so it can reload from the file system cache which has a bandwidth of over 5GB/s (25X faster than my HDD with practically zero latency), GIMP still takes three seconds to load due to all of the processing it does while loading stuff. That's only a 4X speed-up between HDD and best-case/SSD for this example.

Exactly. Software development needs to be rethought with the advent of PCIE SSDs and 3D XPoint(or equivalents). It's gonna take a while. Most probably, NVMe will be even cheaper that SATA SSDs today per GB by the time we start to see real progress in that regard.

 

[firebug11]

So basically right now the bottle neck isn't the bandwidth but actually the processing speed which still struggles to deal with a sata connection that is only 6gbs on an ssd? Even with a i5 6600k overclocked?

 

[Hlsgsz]

So basically right now the bottle neck isn't the bandwidth but actually the processing speed which still struggles to deal with a sata connection that is only 6gbs on an ssd? Even with a i5 6600k overclocked?

Not quite. It doesn't matter how fast the CPU is. Software is still far from optimised for the speeds of an NVMe SSD. And it will be years until it will be. By that time, they will cost alot more reasonably. Go for capacity.

 

[InvalidError]

I do not think we will every see software "optimized to take advantage of NVMe speed", just like we aren't seeing much of a hurry to make use of extra CPU cores/threads: for software to load things faster, the software's initialization code would need to get parallelized too to offload load-time processing to threads and load more stuff in parallel.

Much of the time though, what needs to be loaded has dependencies on stuff that is yet to be loaded and processed. If you take an OS as an example, the computer cannot load the OS kernel before it has gone through POST, loaded the MBR, booted into the MBR code which loads the OS bootloader, then the bootloader loads the OS kernel with critical drivers before handing control to the kernel, then the kernel picks up loading the remainder of drivers, boot-time tasks, GUI, etc. The boot order cannot be circumvented because each subsequent boot stage relies on previous stages completing their tasks. Software does much the same thing with libraries that have their own dependencies nested multiple libraries deep.

Many tasks are intrinsically sequential and will never occur in parallel. At least not without exceptional (read impractical) effort. Unless a task is exceptionally compute-intensive and takes an unacceptable amount of time to complete, it usually just isn't worth the development effort. That's why most games one main thread active ~100% of the time and a bunch of much lighter support threads - developers aren't bothering with delegating processing to threads unless the job is easily decoupled from the main code (ex.: rewriting a configuration or save file) or it is absolutely necessary for performance reasons.

 

[firebug11]

I do not think we will every see software "optimized to take advantage of NVMe speed", just like we aren't seeing much of a hurry to make use of extra CPU cores/threads: for software to load things faster, the software's initialization code would need to get parallelized too to offload load-time processing to threads and load more stuff in parallel.

Much of the time though, what needs to be loaded has dependencies on stuff that is yet to be loaded and processed. If you take an OS as an example, the computer cannot load the OS kernel before it has gone through POST, loaded the MBR, booted into the MBR code which loads the OS bootloader, then the bootloader loads the OS kernel with critical drivers before handing control to the kernel, then the kernel picks up loading the remainder of drivers, boot-time tasks, GUI, etc. The boot order cannot be circumvented because each subsequent boot stage relies on previous stages completing their tasks. Software does much the same thing with libraries that have their own dependencies nested multiple libraries deep.

Many tasks are intrinsically sequential and will never occur in parallel. At least not without exceptional (read impractical) effort. Unless a task is exceptionally compute-intensive and takes an unacceptable amount of time to complete, it usually just isn't worth the development effort. That's why most games one main thread active ~100% of the time and a bunch of much lighter support threads - developers aren't bothering with delegating processing to threads unless the job is easily decoupled from the main code (ex.: rewriting a configuration or save file) or it is absolutely necessary for performance reasons.

I really appreciate your post but feel it strayed a bit from the point (not to insult at all). In your opinion is utilizing the m.2 slot worth it? So say that processes only use 1 core would the sata connection keep up with feeding it enough data and is the m.2 32gbs overkill?

 

[Hlsgsz]

I do not think we will every see software "optimized to take advantage of NVMe speed", just like we aren't seeing much of a hurry to make use of extra CPU cores/threads: for software to load things faster, the software's initialization code would need to get parallelized too to offload load-time processing to threads and load more stuff in parallel.

Much of the time though, what needs to be loaded has dependencies on stuff that is yet to be loaded and processed. If you take an OS as an example, the computer cannot load the OS kernel before it has gone through POST, loaded the MBR, booted into the MBR code which loads the OS bootloader, then the bootloader loads the OS kernel with critical drivers before handing control to the kernel, then the kernel picks up loading the remainder of drivers, boot-time tasks, GUI, etc. The boot order cannot be circumvented because each subsequent boot stage relies on previous stages completing their tasks. Software does much the same thing with libraries that have their own dependencies nested multiple libraries deep.

Many tasks are intrinsically sequential and will never occur in parallel. At least not without exceptional (read impractical) effort. Unless a task is exceptionally compute-intensive and takes an unacceptable amount of time to complete, it usually just isn't worth the development effort. That's why most games one main thread active ~100% of the time and a bunch of much lighter support threads - developers aren't bothering with delegating processing to threads unless the job is easily decoupled from the main code (ex.: rewriting a configuration or save file) or it is absolutely necessary for performance reasons.

Perhaps some wishful thinking on my part as far as teh multithreading part goes would be that this would trickle down from the mobile environment that is bound to go for an increased number of lower clocked cores in order to reduce power usage. APIs should strive for cross platform compatibility in order to reach as wide of an audience as possible, so that may the driving force towards better paralelised libraries overall.

EDIT: sorry for off-topic, OP.

 

[InvalidError]

APIs should strive for cross platform compatibility in order to reach as wide of an audience as possible, so that may the driving force towards better paralelised libraries overall.

The problem with intrinsically serial tasks is that they are intrinsically serial, no amount of research will ever change them much.

For example: how do you parallelize parsing source code or any other sort of heavily contextually structured text like HTML or XML? Since everything is heavily dependent on context, the only way to make any sense of such files is to read it from the top with all dependencies and macro expansions merged in. Attempting to parallelize this intrinsically serial task is not worth the effort since speedup gains here would be negligible at great complexity cost.

 

[Hlsgsz]

You're right. But we should get back to the issue at hand: OP, i totally stand by my assertion that NVMe is not worth it at current prices and capacity is the way to go, and InvalidError has already cocurred in a previous post.