Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

randomascii.wordpress.com

Post reply on HN
Print view View original

11–20 of 255 posts

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

#11

Post by salawat »

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. The click would, but there'd be no guarantee the click handler would execute before background processing resumed, because it'd be considered an event that'd get scheduled after whatever is currently starving the CPU thread.

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

#12

Post by CoastalCoder »

malfist wrote: 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.

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

#13

Post by astrange »

chrsig wrote: post #6
PaulHoule wrote: post #2

Moving the mouse is the worst case scenario for a deep multicore processor because (1) it is a single-threaded latency sensitive task, (2) there are 23 other cores that can grab a lock and prevent the 1 core that matters from doing its job in a timely manner.

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.

Or if it needs code that’s paged out or all cores are thermal limited or the GPU hung. CPU time usually isn’t the limiting factor.

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

#14

Post by PaulHoule »

chrsig wrote: post #6
PaulHoule wrote: post #2

Moving the mouse is the worst case scenario for a deep multicore processor because (1) it is a single-threaded latency sensitive task, (2) there are 23 other cores that can grab a lock and prevent the 1 core that matters from doing its job in a timely manner.

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 might be a just a hardware sprite that can be moved around by writing a few bytes.)

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

#15

Post by toast0 »

CoastalCoder wrote: post #12
malfist wrote: 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.

> 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 they don't let you do anymore work if you've got a fully tuned load that uses all the computing resources.

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

#16

Post by dezgeg »

salawat wrote: 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…

Sure, on the wire USB is a polling protocol. But the polling is done by the host controller hardware, which will raise an interrupt just like PS/2 whenever the device responds to the polling as having data available.

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

#17

Post by taeric »

salawat wrote: 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…

The article is about a bug in process destruction, if I'm not mistaken. The mouse bit is a bit of an aside. More of an obvious symptom that something is wrong.

Not that interrupt based input processing didn't have some advantages. Just this shouldn't be one of them.

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

#18

Post by eloff »

toast0 wrote: post #15
CoastalCoder wrote: post #12

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…

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.

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

#20

Post by FpUser »

toast0 wrote: post #15
CoastalCoder wrote: post #12

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…

Many years ago a customer on a single core computer had problems of heavy video stutter in my product. It was multithreaded and ran as I recall 5 threads (GUI, video decoding, 3d pipeline, device control and computation). Others did not have this problem. After investigation it turned out that said customer had hyperthreading disabled in BIOS. Enabling it fixed the problem instantly.

So "real" or not but from my experience HT does work to the benefit.

Post reply on HN