The Sandy Bridge Core i7 3960X Benchmarked Against Today's Six-Core / 12 Thread AMD/Intel CPUs

[yokem55]

Agree 100%. In my opinion, the cloud providers are the ones that got really screwed with the Intel mitigations, because they have to prioritize security and keep them on. But for regular ol' you and I, that should be off (on the condition like you said that you're being mindful and not running malicious code).

And I generally agree with you - But you do have to be pretty mindful of where the code you are running is coming from. Ie making sure all your repo's are signed, don't install random .deb's, tarballs, appimages, etc. Even building electron apps from source can be risky because of the security shit-show that npm is. The same problem with apps installed with pip/pypi. Also you have to cross your fingers that this stuff never becomes easily exploitable via javascript in your browser...

[perpetually high]

I agree that mitigations=off is good for notebook&desktop machines (assuming the user ensures that the machine never runs malicious code).

On the other hand, cloud machine providers shouldn't boot the machines with mitigations=off.

Agree 100%. In my opinion, the cloud providers are the ones that got really screwed with the Intel mitigations, because they have to prioritize security and keep them on. But for regular ol' you and I, that should be off (on the condition like you said that you're being mindful and not running malicious code).

(nice -n12 make -j$(nproc), NVMe SSD)

Btw: that nice command is inverted. That's giving the process a priority of +12 (lower priority) instead of -12 (higher priority) which I'm sure is what you wanted.

I find "nice -n -12" to be easier to remember and more intuitive than the double hyphen (nice --12) and prevents accidentically using the positive number instead of negative.

On a quick side note - with Feral's GameMode, I find a nice value of -4 to be the best. Since PulseAudio runs at -11, it seems -12 through -20 caused some stuttering in games.

[perpetually high]

May I ask, which are the use cases you are noticing the difference? I'm still running 250Hz, CONFIG_PREEMPT off, since I can't really notice the latency even with this setup. Maybe I have just adapted to not "feel" it, but I still think there can't be much room for improvement that would be meaningful in my desktop experience.

In just general day-to-day multitasking use, web browsing, application start time, etc. I don't attribute this all to the 1000 hz timer or preempt, the BFQ scheduler helps a lot as well (previously was using 'none' which was quick also, but kinda dumb).

GNOME 3.34, even more help. I posted a gif the other day of just opening apps to give you an example. Also, using "preload" (sudo apt install preload) still makes a lot of sense for today's desktops, but again, you're not going to find that kind of stuff installed and enabled by default.

For compiling software, using "make -j4" (or however many threads you have) and ccache helps speed things up in that department. Compling the kernel with ccache takes only about 6-7 minutes for me. (and that's with the standard Ubuntu config + my changes)

Things like using the Feral's GameMode and the "performance" governor (intel_pstate driver) make sense for gaming also. When I'm not gaming though, I leave it on powersave and find it performs well.

My main point though in this thread was to highlight booting with the kernel parameter "mitigations=off" on Intel systems.

I'm still waiting for a decent (non-Nvidia) GPU with path tracing to come out, before I consider building a new PC. Right now, I'm stuck with my i7-3720QM, which is OK even for development work as of now, but it feels like single threaded games murder that CPU.

[dispat0r]

For best performance I would consult the clear linux kernel defaults:

https://github.com/clearlinux-pkgs/linux/blob/master/config

On my desktop I just use these with full preempt. You can also add the patches from this repo for better performance.

[pmorph]

Then you couple that with BFQ scheduler and maybe a mitigations=off for good measures, and the system really flies.

May I ask, which are the use cases you are noticing the difference? I'm still running 250Hz, CONFIG_PREEMPT off, since I can't really notice the latency even with this setup. Maybe I have just adapted to not "feel" it, but I still think there can't be much room for improvement that would be meaningful in my desktop experience.

[xpue]

1000hz timer

... Degrades performance.

[perpetually high]

Some notes:

...

Good info - thanks.

In my situation I'm more than happy to give up a little IPC for more latency. To me, latency is king on desktop. On a server, probably throughput is. It really all depends on the use cases of desktop vs servers, and I agree everyone has to assess their own situation.

The kernel is built "generic-x86_64" to satisfy everyone, which makes sense. But likely, if you're an enthusiast trying to make your system as efficient and optimized as possible, feeding it a hearty "-march=native" does a kernel good. I've mentioned before - lots of goodies in the kernel config that improve performance and latency that wouldn't make sense to enable by default, but doesn't mean they shouldn't be enabled for your system.

About the 1000 Hz kernel, here's what Linus/the kernel says about it, and I find it works well for my 4c/4t:



In respect to preemptive kernel, it suits my needs on desktop as the image below explains. The combo of this + 1000 hz has made my system incredibly responsive. Then you couple that with BFQ scheduler and maybe a mitigations=off for good measures, and the system really flies.

[perpetually high]

Wow, that i7-3960X (released Q1'11) is pathetically slow for 6c/12t.

I ran a couple tests out of curiosity on my 4c/4t Haswell i5-4670K (released Q2'13), and got a ctx-clock score of 142, which beats all the processors in this test. (3600X was 167, 2600X was 180, i7-8700K was 913, and i7-3960X was 1103)

This is exactly why I and many others enable mitigations=off. You're leaving way too much performance on the table otherwise, especially for desktops. I think these processors are still very capable. It's also why I bother compiling the kernel with -march=haswell, -O3, 1000hz timer, preemptive kernel (low-latency), etc etc. I think it matters.

Btw: I ran the ctx-clock benchmark with the recent Intel FSGSBASE patches from yesterday and it received the same score as without the patches. Both got a score of 142. Figured this was a more relevant test to see how the patches affected context switching, but I'll leave the benchmarking to the pros. For now, I'm leaving the patches enabled as it seems stable so far.

EDIT: Also ran the ctx-clock on my 2010 MacBook Pro running linux and got a score of 162. This i5-520M beat out the Ryzen 3600X!

[skeevy420]

It depends on your tasks, if they are not using or cannot meaningful profit from AVX/AVX, then it is still fine as in many games. I've used a Xeon X5675 @ 4.2 Ghz for gaming on Windows still until this summer. As the security mitigations take more of a performance hit on these older architectures, I'd suggest to disable all of these for a gaming box.

That. The x5687's in my current setup are just fine for most needs though it's obvious that I'm CPU limited in regards to modern gaming (2017+ games). I'll probably upgrade next year or sooner if I can find some good deals on corporate Zen workstation lots on eBay.