5~30% CPU speed reduction to your Intel CPU forecast

I’d be interested to see how this effects our modelling machines, however, for stability reasons, we don’t connect these to the network in any way, so I don’t think we’ll be updating anytime soon.

It’s going to affect all o/ses AFAIK.

Hmm. Not much info out there yet about the exact nature of the hardware bug but the software fix looks nasty.

I was going to write a short pice about virtual address management on x86 CPUs but as this has come up here is a bit about it now.

Once an x86 CPU switches into 32/64 bit protected mode early in the boot process it is using virtual addressing and it maps these addesses into physical memory using page tables set up by the OS.

The CPU provides four levels of hardware memory and execution protection but Windows only uses 0 and 3 which it calls kernel and user modes.

On a 32 bit CPU there is 4GB of virtual address space and Windows normally reserves the top 2GB for its own kernel mode code.

When you launch a user mode program Windows creates a process for its thread/s to run in.

A process is like a container and it holds together all the info Windows needs to run a program. This is called the context.

Part of the context describes the virtual address range the process has been allocated.

A process will usuall be given the bottom 2GB of virtual addresses to use for its own private user mode threads. These virtual addresses are mapped into physical memory using page tables stored in the context of the process.

Every process also gets the 2GB of common kernel mode virtual addresses mapped into its range but this range is mapped into physical memory using the kernal mode page tables common to the whole system.

User mode threads cannot access kernel mode addresses directly but they do need to call OS services so the CPU provides a special service call instruction that puts the CPU into  kernel mode and executes a predefined service dispatch routine.

The kerel mode address range has to be included in every process address range or Windows would generate an access violation fault every time a system call was made.

Hardware CPU mode protection is the only thing stopping user code from accessing kernel memory so if a bug has compromised this then its a really big deal !

Hope thats clearer than mud ?

Problem is Bob, even with the performance hit the Intel’s will still walk all over the FX-6300 in the benchmarks.

This is what makes me think that the average user won’t notice a thing. I switch between the FX-6300 and i3-6300 desktops and an i5-6200U laptop. The one thing they all have in common is an SSD. The i3 boots quicker but it’s only a second or two, in use I cannot tell the difference. Users of the low cost low power SOC laptops are more likely to be those that get the noticeable hit.

Of course none of this applies to boxes where the CPU is deliberately hammered, like rendering or virtual machine hosts. None of that applies to me any more. My AWS EC2 t2.micro server CPU rarely hits 2% looking after 11 APs on 8 sites.

I did say average user, gamers are not average users.

But having practical every day experience of switching between machines that can have a single threaded speed difference of more than 30% link I cannot tell the difference in use. I know the i3 boots quicker but it’s only a second or two and you’d only notice if they were side by side. Put me on a machine with an FX-6300 with an SSD and an i7 with a spinner and I would notice the difference and it wouldn’t be the CPU.

I’m sure the geek and data centre worlds will (rightly) be awash with tales of woe, but Joe Public and home / SMB general purpose servers? We will see but I doubt it will be significant.