Live data from Hacker News

24-core CPU and I can’t move my mouse (2017)

randomascii.wordpress.com

21–30 of 255 posts

Re: 24-core CPU and I can’t move my mouse (2017)

#21
post #11

If I recall, this is mainly caused by the shift to USB as the connector du jour. Since it's a poll centric protocol, under heavy load, system responsiveness decays. Back in the days of P/S 2, where input was interrupt driven, the background tasks would be interrupted by input coming in, ensuring the user could move the mouse around. Now whether they could get the outcome of a click to register is a different story. T…

As I understand it, the polling is done by the USB controller, not the operating system or anything happening in the system's CPU.

Re: 24-core CPU and I can’t move my mouse (2017)

#22
post #15

Earlier quoted context omitted.

> Hyperthreads aren't real CPU cores I can't think of a good principled reason to say SMT cores aren't "real". I'm assuming the answer isn't "because they share some computing stuff". What I think you'd call "real" cores also share resources like L2/L3 caches, sometimes DMA engines, etc. And IIRC, each Intel SMT (hyper-thread) unit has its on instruction pointer and (non-SIMD?) register set.

> And IIRC, each Intel SMT (hyper-thread) unit has its on instruction pointer and (non-SIMD?) register set. I believe the SMTs share the register rename storage, which I'd say is the register set more than the 'architectural registers' But I'd say the reason they're not real is because they don't increase the maximum instructions per clock. With many loads, they do increase the average instructions per clock, but the…

I don’t know how many hardware revisions Intel went through where every benchmark said hyperthreading was slower than turning it off, but it was a lot. It became Lucy’s football at some point.

And in these days of post-Dennard scaling, you have thermal throttling, so idle cycles aren’t actually idle, they’re allowing the heat sink to catch up with heat production.

Re: 24-core CPU and I can’t move my mouse (2017)

#23
post #6

Earlier quoted context omitted.

With regard to latency sensitivity, with so many cores available, a single core could be dedicated to processing mouse input. Of course, if there's a lock in the way that's held, that's still a problem.

For a modern system like Wayland or WDM, the display compositor gets rectangles of pixels from the applications, copies those into a big rectangle it sends to the rasterizer. Just before it does that, it draws on a mouse cursor. It also has to communicate with the applications about what image to draw so you have to deal with multiple threads no matter what. (Unless you go back to the late 8-bit era where the cursor…

I believe the mouse cursor is still often a hardware sprite today.

Re: 24-core CPU and I can’t move my mouse (2017)

#26
post #18
post #15

Earlier quoted context omitted.

> And IIRC, each Intel SMT (hyper-thread) unit has its on instruction pointer and (non-SIMD?) register set. I believe the SMTs share the register rename storage, which I'd say is the register set more than the 'architectural registers' But I'd say the reason they're not real is because they don't increase the maximum instructions per clock. With many loads, they do increase the average instructions per clock, but the…

In reality you never have a finely tuned load that uses all the resources all of the time. Processors spend a lot of time waiting for memory, so hyperthreading allows for better utilization of compute. It’s rare to have a workload that benefits from turning it off, and in those cases it’s usually because the hyperthread is hurting the cache hit rate enough to offset the gains.

Both threads are waiting on the same memory pipeline. The actual performance has always lagged behind the theory

Re: 24-core CPU and I can’t move my mouse (2017)

#27
post #4

Earlier quoted context omitted.

Where are the mouse coprocessor equipped computers?

Mouse cursors are mostly handled in hardware. GPUs composit the cursor during scanout, so all the OS has to do is calculate the new coordinates of the cursor and tell the GPU about them.

> Mouse cursors are mostly handled in hardware. GPUs composit the cursor during scanout, so all the OS has to do is calculate the new coordinates of the cursor and tell the GPU about them.

Is this true on modern Linux DEs (e.g. on KDE Plasma)?

Is it also true on Windows and macOS?

Re: 24-core CPU and I can’t move my mouse (2017)

#28
post #26
post #18

Earlier quoted context omitted.

In reality you never have a finely tuned load that uses all the resources all of the time. Processors spend a lot of time waiting for memory, so hyperthreading allows for better utilization of compute. It’s rare to have a workload that benefits from turning it off, and in those cases it’s usually because the hyperthread is hurting the cache hit rate enough to offset the gains.

Both threads are waiting on the same memory pipeline. The actual performance has always lagged behind the theory

But not the same memory operations. Unless your code fully saturates the memory bandwidth, which is rare, you get some gains here.

Re: 24-core CPU and I can’t move my mouse (2017)

#30
post #5

Hyperthreads aren't real CPU cores, claiming that your 48 hyperthreads were "only" 50% utilized means all the real cores under the hood are fully utilized.

> Hyperthreads aren't real CPU cores I can't think of a good principled reason to say SMT cores aren't "real". I'm assuming the answer isn't "because they share some computing stuff". What I think you'd call "real" cores also share resources like L2/L3 caches, sometimes DMA engines, etc. And IIRC, each Intel SMT (hyper-thread) unit has its on instruction pointer and (non-SIMD?) register set.

> I can't think of a good principled reason to say SMT cores aren't "real".

It really depends on your definition of "real", yes you can treat them like "real" independent cores but that's not ideal for performance because under the hood they're not actually independent. Your operating system is aware of this and will often avoid scheduling two tasks onto the same physical core unless it has to. If you have 20 logical cores (10 physical ones with hyperthreading) and 10 tasks to execute, the OS scheduler will usually allocate one task to each physical core and leave the other logical core idle.

Post reply on HN