Number of processor cores confusion

[Liam Proven]

On Tue, 10 Nov 2020 at 15:22, Chris Green <cl at isbd.net> wrote:

> However, in reality, *very few* things running on your computer ever
> use more than one thread/core.  Almost all of the time only one is
> being used.

Largely true.

To understand why...
Many decades ago, IBM threw one of their best managers, Fred Brooks,
and a ton of extra programmers at a large mainframe OS project that
was running late. In vain he protested that more engineers did not
help and indeed made the problem worse. In the end he wrote a famous
book about it, called _the Mythical Man-Month_.

To understand why most code is single-threaded, you have to read it.
Better still, buy 2 copies so you can read it in half the time!

> I have only seen a couple of rather specialised bits of code that
> manage to use more than one core, one of them was the password security
> checking program crack_known_hosts.py,

Encoding audio & video data works well. Different cores can work  on
different chunks of sound or video, because the results of each block
do not affect the other blocks. You could divide a movie into quarters
and encode #3 then #2 then #4 then #1 and the end result is identical.

Try sorting a list of names into alphabetical order in quarters and it
won't work, though.

> I think I also noticed a static
> web site generating program doing it too.

Seems less likely, but OK.

It is often _possible_ to do but doesn't help. E.g. if you sort a list
into order in 4 chunks, sure, it's 4× as fast. But you end up with 4
sorted lists and then must combine them, and that last step takes  as
long as just sorting the big list. Even if you combine pairs of lists
into 2 lists, then combine  too -- you spend more time combining than
sorting.

*But* if perhaps your computer stays much more responsive as it works,
and the whole unsorted list (read "database") remains usable as the
chunks are being sorted in the background and only gets locked for a
fraction of a second at the end... it might be worth a slower
algorithm.

This was the bet made when Be wrote BeOS. Everything possible is
multithreaded, as the original BeBox computer was the first
mass-market end-user multiprocessor computer. Some things -- OK, a lot
of things -- might be no quicker, or not noticeably quicker on 2 CPUs
but suddenly work much better if you have 8 or 16 -- but the company
bet that in future most PCs would be multi-processor.

They were absolutely right but didn't survive long enough to benefit.

Haiku is the FOSS continuation but it's a lot bigger and slower.

Unix took the other approach. The core design is from the 1960s when
computers had just tens of KB of memory and a few meg of disk, but
were shared by dozens of users on dumb serial text terminals. So
everything is text, everything is centred on the hard disk, programs
are small and you chain them together with pipes.

*None* of these assumptions are true any more but it achieved critical mass.

When PCs got multiple CPUs, the programmers went through trying to
divide up the tasks in the kernel so that some bits could run
side-by-side, marking the dangerous bits that must not with
mutual-exclusion signals -- MUTEXes. Originally there was one big one
that locked the whole kernel; this was removed in Linux 2.2 if I
remember correctly.

Similarly, Firefox painfully was broken into 2 then 4 communicating
processes. Google took the brute-force approach with Chrome: each tab
is a process, communicating with a front-end that draws the window
frame. Faster but this approach eats RAM and will use all your CPU
cores if it can.

But yes, you're absolutely right, most user programs don't, at all.
It's too hard for too little gain. Languages like C and to a slightly
lesser extent C++ are very bad at this, and in *nix, _everything_ is
implemented in C or C++.

> It's difficult to write multi-threaded code so most people don't, the
> only (moderately) easy candidates for it are things which do intensive
> processor bound things without any I/O (like the above password
> cracking and/or image processing programs).  Anything that uses system
> libraries and I/O is almost inevitably single threaded.

I'd slightly dispute that. I/O is limiting, sure, but these days you
can read gigs of (say) movie data into RAM off a single disk, work on
it, compress it, re-encode it and only write it back later. Many
system libraries and the kernel itself are re-entrant. It's getting
better but only very slowly.

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lproven at cix.co.uk – gMail/gTalk/gHangouts: lproven at gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053