Failure to provide a way to turn off the unsafe features is what's irresponsible here; if they'd done is the safe & responsible way, a microcode update or even flipping a bit in an already-exposed MSR would have fixed it.
-
-
Wouldn’t an execution stall with hyper threading still hide a new TLB miss? For example, speculative execution isn’t that much help if you’re stalled anyways. So increasing the miss rate may not affect the performance that dramatically in that case.
-
Whereas if I wrote “perfect” code with no stalls, the instruction fetch would be dramatically more noticeable, and this is what scares me. Network hardware, system level processes, etc... are usually optimized this way and they are the most critical.
-
These processes slowing down by even 10% is an internet level outage in the making.
-
The latency would propagate exponentially throughout the internet going up the levels of abstraction. Higher dns latency, slower tls/crypto, drop in throughout, then the latency of high-level services would increase by an order of magnitude, then the applications depending on it
-
This is blown way out of proportion. Many of those levels aren't remotely cpu-bound, and if one increases latency, it _lightens_ load on ones that depend on it rather than increasing load.
-
Networking hardware is certainly cpu bound in many cases. Even then it’s not just cpu load, it’s latency. If it takes me 50 microseconds to execute a branch when it used to be sub-microsecond, then that adds to the overall latency of the system.
-
You're off by 3 orders of magnitude.
-
To clarify my concern isn’t for “oh god my fleet size isn’t big enough” propagated across every cloud provider. My concern is where we are latency sensitive, the latency will propogate exponentially. Next thing I know somebody gonna be stealing my kills in battlefront.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.