1

The following is htop showing the calculation of all of the digits of Pi, using a slightly modified version of ROSETTACODE's java program here. I understand from Single thread program to make use of multiple cores that other 'worker' threads pop up to perform background tasks.

htop

My question is why non of the six available cores is loaded to 100%? My code modification simply excludes printing of Pi's digits to the screen. That means that there is no waiting for the graphics components. So there is no restriction on the processing speed that I can see. I would expect the thread on the critical path of any single threaded application to achieve 100%. Why doesn't it?

Paul Uszak
  • 377
  • 4
  • 18
  • Seems it exceeded load at 102% – Andreas May 13 '19 at 23:47
  • @Andreas But the bars against the cores don't reflect that. The machine wasn't doing anything else. Is this more `htop` than multi-threading then? – Paul Uszak May 13 '19 at 23:53
  • 1
    You are assuming that a thread is pinned to a single core, which is known as [*Processor Affinity*](https://en.wikipedia.org/wiki/Processor_affinity), but the OS is not required to do that, see e.g. [How does a single thread run on multiple cores?](https://softwareengineering.stackexchange.com/q/349972/202153) – Andreas May 14 '19 at 00:00
  • @Andreas No, not at all. My question mustn't be clear enough. I know the threads bounce. But I would expect the most resource intensive (critical path) thread to use 100% of any core. The other 'worker' threads would use what they need, but less than 100% as they're dependent on the critical path thread. Shouldn't one cpu bar always be full, even if it bounces around? Otherwise the cpu is intentionally slowing my program down for no reason whatsoever... – Paul Uszak May 14 '19 at 00:20
  • 2
    If your single thread spends half its time on core 1, a quarter of its time on core 2, and a quarter of its time on core 3, then it will use 50%, 25%, and 25% of those cores. – Matt Timmermans May 14 '19 at 01:35
  • @PaulUszak Please read the explanation in the [answer](https://softwareengineering.stackexchange.com/a/349982/202153) in the link I provided. Even for a single-threaded program, that one-and-only thread may bounce around between cores, unless you (or the OS) has enabled processor affinity. Even if that thread is 100% CPU-bound, with no I/O wait states, it still only gets one time slice at a time, and each slice may be assigned by the OS scheduler to a different core. – Andreas May 14 '19 at 02:51
  • @Andreas But that link is for a single thread. My question is about Java, and `htop` clearly shows several Java threads (like GC) just running my single threaded Pi code. Are you saying there is a limiter that stops any core running at 100% if there are other associated background threads? So the cores are just sat there artificially unused? I don't think that I get this... – Paul Uszak May 14 '19 at 03:23
  • 1
    I'm saying, that *any* thread will run on *any* processor at *any* time. Sure, Java starts several background threads, but they are all idle, so if your Java code is single-threaded, for all intends and purposes your program is too. Did you look at the Wikipedia article describing **processor affinity**? What you're postulating, that the program should use one processor 100%, is only true if the processor affinity is in play. By default it is not, so the CPU load of the thread is scattered across multiple processors, as you can clearly see, since the sum of the 6 processors is about 100%. – Andreas May 14 '19 at 03:29

0 Answers0