Spectre mitigations murder userspace performance • Hacker News Board

Re: Spectre mitigations murder userspace performance

#271

Post by wffurr » Sun, Jun 20, 2021, 11:55 AM UTC

rmdashrfstar wrote: post #257

quotemstr wrote: post #229

Earlier quoted context omitted.

I'll make a deal with you: I'll agree to turn down speculative execution in hardware if 1) you can solve the VLIW scheduling problem, and 2) you transition the entire computing ecosystem to a JIT model. These are the things we would need to claw back the performance we would lose through disabling speculation. You can look at speculation (I'm handwaving a lot here, bear with me) as the processor hardware dynamically…

> Honestly, I think the world we'd create by solving both these problems would be a better world. I really don't like how we can't program the processor's speculation engine and uOP scheduler. I'd love to be able to do that. Have you started working on any solutions for 1 and 2?

#2 sounds like WebAssembly with WASI.

Re: Spectre mitigations murder userspace performance

#272

Post by asdfasgasdgasdg » Sun, Jun 20, 2021, 12:03 PM UTC

rkagerer wrote: post #173

rkagerer wrote: post #158

Earlier quoted context omitted.

I'd like some more technical details on what exactly InSpectre does (specifically for the Meltdown patch). e.g. Does it just flip a registry key? Rewrite a microcode patch somewhere? Couldn't find an explanation in the software (even under Show Tech Details) or on their site; could you point me to it? Also, do all the major browsers now have their own mitigations built in?

Answering my own Question #1: Looks like it sets values for FeatureSettingsOverride and FeatureSettingsOverrideMask under the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" registry key. FeatureSettingsOverride is a bit field where bit 0 controls the mitigation for CVE-2017-5715 (Spectre) and bit 1 controls it for CVE-2017-5754 (Meltdown). If the bit value is 0 the correspondi…

For anyone considering whether to disable these for desktop performance, I tried to do some research on how much it helps, at least for my workload. From what I was able to read, for gaming, the performance differences are negligible. There also seems to be some indication that disabling mitigations is also harmful to performance on more recent CPUs, since more and more of the mitigations are being baked into the silicon.

https://www.reddit.com/r/intel/comments/kp6b6i/how_bad_is_it...

Re: Spectre mitigations murder userspace performance

#273

Post by p_l » Sun, Jun 20, 2021, 12:44 PM UTC

giantrobot wrote: post #201

nickpeterson wrote: post #3

I’ve made similar comments in the past but I think we’re just trying to predict too much about what programs are trying to do in hardware. I’d rather have simple hardware that is light on energy requirements and easier to understand. I don’t think software as an industry really has a “this chip isn’t fast enough problem”. Most of the real slowdowns anyone has in day to day performance has more to do with inefficient…

> Look at old game consoles (like a regular old PlayStation) and what they were able to render on what today would be laughably slow hardware. They could do it because developers learned the stack inside and out. You're oversimplifying the situation and drawing conclusions from it. The PSX had dedicated hardware for geometry transforms, video decoding, sound processing, and rasterizing. The CPU was used for game logi…

The description sounds more like PS4 than PS2 (maybe PSX was simpler - PS3 is closer to PS4 and "normal" programming). I've seen numerous examples of how involved CPU was in rendering, especially on PS2, due to special units being exposed as MIPS coprocessors. Efficient rendering meant you had to keep the pipelines happy and that could require significant amount of assembly wrangling.

I remember reading about how GTA3 on PS2 was a watershed moment, because it was a proof you could use a somewhat more generic engine - whereas console programming had a heavy amount of assembly focus due to historical reasons.

Re: Spectre mitigations murder userspace performance

#274

Post by p_l » Sun, Jun 20, 2021, 12:59 PM UTC

homerowilson wrote: post #100

temac wrote: post #35

Earlier quoted context omitted.

This has been tried (not on vaporhardware Mill, I'm more thinking about e.g. Intel Itanium) and it failed. The reason is extremely simple: a speculative OOO processor optimizes dynamically. If you switch that with static compile time optimizations, you are bound to only be as fast as before in some quite limited parameter ranges (like: number of entries in a hash table, size of an image, etc.)

Also don't forget the really interesting Transmeta processors, also ultimately a failure. VLIW is very difficult in practice.

Transmeta were VLIW, yes, but weren't EPIC - which is the main difference involved. VLIW just means there's a long instruction word, usually targeting multiple units, but it doesn't necessarily mean there's no dynamic reshuffle in the CPU architecture or anything like that.

EPIC stood for Explicitly Parallel Instruction Computing, and took the "let's push it all to compiler" to the extreme. Itanium was never supposed to have any form of branch prediction or OOB, because it was supposed to be handled by the compiler.

This led to someone quipping that Itanium was a very fast DSP, but ridiculously expensive.

Re: Spectre mitigations murder userspace performance

#275

Post by p_l » Sun, Jun 20, 2021, 1:04 PM UTC

Popegaf wrote: post #266

So if I understand this right, CPUs try to predict what operations are going to be made in order to gain performance, but instead introduced a vuln that killed performance? Wouldn't the logical thing be then to get rid of the predictions on hardware in order to be able to turn off these mitigations? Are there CPUs out there / being made without these SoC predictions?

The techniques used to make CPUs fast have possible vulnureable areas (not all of it is due to Out-Of-Order Execution, some was due to optimizations made on top).

The mitigations introduced stalls into those mechanism, clearing some of the state, resulting in slowdowns.

However, the mitigations are not as big slowdowns as not having the speculative execution mechanism at all.

Re: Spectre mitigations murder userspace performance

#276

Post by emilfihlman » Sun, Jun 20, 2021, 1:13 PM UTC

quotemstr wrote: post #232

emilfihlman wrote: post #174

Earlier quoted context omitted.

No. Io_uring is a message passing system where you tell the kernel to do something and let you know when it's done. Syscall chaining refers to having the kernel execute consecutive systemcalls without switching the context back to userspace. An example of this might be closing a multitude of file descriptors or registering signals or writing the same data to multiple fds etc, which becomes prohibitely expensive if yo…

> Syscall chaining refers to having the kernel execute consecutive systemcalls without switching the context back to userspace. io_uring already gives you that. You can submit multiple operations in a batch and link the operations together so that if one operation in a chain of linked operations fails, io_uring won't try to execute the rest.

Which is not syscall chaining, but message chaining, of io.

Re: Spectre mitigations murder userspace performance

#277

Post by emilfihlman » Sun, Jun 20, 2021, 1:13 PM UTC

dsp wrote: post #236

emilfihlman wrote: post #174

Earlier quoted context omitted.

No. Io_uring is a message passing system where you tell the kernel to do something and let you know when it's done. Syscall chaining refers to having the kernel execute consecutive systemcalls without switching the context back to userspace. An example of this might be closing a multitude of file descriptors or registering signals or writing the same data to multiple fds etc, which becomes prohibitely expensive if yo…

> having the kernel execute consecutive systemcalls without switching the context io_uring enables exactly this https://kernel.dk/io_uring.pdf

Only for io, which is not the same thing.

Re: Spectre mitigations murder userspace performance

#278

Post by Popegaf » Sun, Jun 20, 2021, 2:03 PM UTC

dkarras wrote: post #270

Popegaf wrote: post #266

So if I understand this right, CPUs try to predict what operations are going to be made in order to gain performance, but instead introduced a vuln that killed performance? Wouldn't the logical thing be then to get rid of the predictions on hardware in order to be able to turn off these mitigations? Are there CPUs out there / being made without these SoC predictions?

I'm not sure if I got you right: The performance boost with speculative execution is massive. It introduces a vuln. It is the fix for that vuln that kills the performance.

What I'm saying is if the fix for the vuln negates the performance boost from speculative execucution, then the net outcome is 0 performance boost and speculative execution might as well be removed entirely. It wouldn't surprise me if it just costs more energy to keep the vuln and mitigation active at the same time.

Re: Spectre mitigations murder userspace performance

#279

Post by mhuffman » Sun, Jun 20, 2021, 2:30 PM UTC

josteink wrote: post #269

saagarjha wrote: post #267

Earlier quoted context omitted.

This is often the same as saying "how about you quit your job".

But why does companies use slack if “everyone” hates it? For once, I’ve never been to a company which uses it. There are literally countless options in the IM/groupware field which is not Slack.

The only two I have seen in most places are Slack and Teams.

Re: Spectre mitigations murder userspace performance

#280

Post by ghoward » Sun, Jun 20, 2021, 2:38 PM UTC

astrange wrote: post #264

ghoward wrote: post #256

Earlier quoted context omitted.

You have good points, but I think you misunderstand the post in many ways. First, you do realize that there already has been an OS that has been formally verified, right? It's called seL4. There is also a C compiler that has been formally verified. It's called CompCert. So there is a clear path to get there on the software side. Second, I am not referring to dynamic linking. Dynamic linking requires jump tables becau…

> First, you do realize that there already has been an OS that has been formally verified, right? It's called seL4. There is also a C compiler that has been formally verified. It's called CompCert. So there is a clear path to get there on the software side. CompCert has not actually been formally verified - only the middle-end has. The C preprocessor and assembler aren't, the frontend formerly wasn't (but I think is…

Fair points.

Regarding "formally verified," I believe the "formal" refers to the formal in formal methods, but I agree that it can be weaselly.

In the case of seL4, however, I don't think it is because they are incredibly precise about defining their assumptions. They have verified the machine code for various architectures, subject to those assumptions.