CPU intensive tasks do not improve with an SSD.

[edbarx]

Solid State Disks, although using no mechanical disks, are a common thread title often with claims that they improve performance. The latter is enhanced as data saved on SSDs does not involve any mechanical parts. Reading is done via MOSFETs which have very low response times. I am writing because I see the latter as the only significant advantage coming off the use of an SSD. CPU intensive tasks, in my logic, do not improve if an SSD is used instead of a hard drive.

[RU55EL]

Technically speaking, if the CPU intensive task involves reading and writing to the SSD, then there is an improvement in performance compared to the same computer with a mechanical hard drive, even if the improvement is so slight that it is virtually imperceptible.

But, basically speaking, yes a SSD won't improve the performance of CPU intensive tasks. It will improve the performance of hard drive intensive tasks.

Installing Debian on a SSD, in this computer, has shorted the boot time to the point where I can re-boot, from hitting the enter key at [shutdown -r now] till GUI login, in about 17 seconds. I can still remember booting my old 386 with 2MB of ram and a 120MB SCSI drive in less than 5 minutes.

[Bulkley]

What do you two think of installing most of the OS to a small SSD and storage to a larger mechanical drive?

[RU55EL]

That is my preferred configuration. Root partition, and swap (if you decide to use one), on a small SSD, and /home on a good mechanical hard disk. I think that provides good performance advantage without breaking the bank.

I have a few Intel NUC computers with a 120GB SSDs and a 1TB hard disks. I use 40GB of the SSD for root and swap partitions. The 1TB mechanical drive is configured for /home. The remainder of the SSD storage I configure as a "fast" storage partition. If I were to do it again, I would just get a 32 or 64GB SSD and use the whole thing for the root and swap partitions and hopefully save a few bucks.

[edbarx]

Technically speaking, if the CPU intensive task involves reading and writing to the SSD, then there is an improvement in performance compared to the same computer with a mechanical hard drive

Linux provides the mechanisms to get a similar, if not better, performance using a computer's RAM instead of a disk. I am talking about file systems like tmpfs which is mounted on /run. Such a filesystem can be synchronously loaded and saved to disk when a process using it is started and stopped respectively.

[pylkko]

I have never seen anybody claim that SSD's enhance a computer performance in the sense that everything would be faster. If someone really claims that somewhere, then unfortunately they are simply wrong.

SSD's only have better throughput and seek times than traditional spinning drives. Throughput enhances large write speeds, so that if you transfer large many GB size files they will transfer faster. This is nice and all and the manufacturers like to remind us of that all the time, but in the majority of so called "average computer use" this plays small role because almost all of the I/O action is going to be small size random mixed write/reads and not massive sequential reads...

But the IOPS (Input/Output Operations per Second) differences for 4 KB read/write (a range corresponding tonormal OS I/O activity) is usually in the range of 50-150x or at times even more better for SSD's compared to HDD's. This is why you see the immense performace enhancements when suddenly large amounts of data need to be read from here and there, like when booting or starting a large program.

Linux provides the mechanisms to get a similar, if not better, performance using a computer's RAM instead of a disk. I am talking about file systems like tmpfs which is mounted on /run. Such a filesystem can be synchronously loaded and saved to disk when a process using it is started and stopped respectively.

You make it sound as if Linux would somehow make an SSD irrelevant and that the two are "mutually exclusive". But certainly nothing prevents one from using both a Linux kernel and an SSD simultaneously. Not only that but how would you replace a storage drive entirely with RAM? Do you mean like buying enough RAM that you can boot slowly from spinning HDD, open all your programs into RAM, never have to do fast write backs, and then just never reboot? Or how else would Linux know before you place the command that you want to open e.g LibreOffice? I think there is a program called "preload" that analyzes the users use patters and with that data in mind attempts to "guess" what programs to read to RAM before the user actually opens them so that when it opens in can open them straight from RAM.

[acewiza]

I've been running my personal systems with separate drives for system/data for decades as a best practice approach that's been the defacto standard in commercial/enterprise systems since like forever. Moving to SSD's on the system side over the past few years has shown me a dramatic, if only anecdotal performance improvement on those machines. Any benchmark comparison or evaluation of SSD performance specific to CPU-intensive tasks would need to be done with carefully controlled I/O criteria compared to static baselines of both legacy and solid state drives. I suspect the results would be quite varied.

[dasein]

In similarly earth-shattering news, gigabit ethernet also doesn't help CPU-bound tasks.