General > General Technical Chat

why did 70/80/90 only have 1 cpu if cpus where so slow?

<< < (8/10) > >>

m k:

--- Quote from: BillyO on March 26, 2023, 04:20:28 pm ---In the 80's DEC had many systems with multiple processors (VAX clusters) and even had a PC, the DEC Rainbow 100 that had 2 processors.

--- End quote ---

April 19, 1988
long-awaited true multiprocessing release 5.0 of the VMS
https://techmonitor.ai/technology/dec_accompanies_vax_6200_multi_processors_with_vms_50_release_new_software_pricing

David Hess:
Without caches, CPU clock speeds were limited by memory access time so adding additional CPUs would have little benefit; they would have had to wait for memory access anyway.

abeyer:

--- Quote from: tooki on March 29, 2023, 07:46:45 am ---but adding that second CPU massively improved system responsiveness.

--- End quote ---

I kinda wonder how much of that was early OSX just being so abysmally unresponsive that anything would have improved it massively, though.

tooki:

--- Quote from: abeyer on March 30, 2023, 01:45:51 am ---
--- Quote from: tooki on March 29, 2023, 07:46:45 am ---but adding that second CPU massively improved system responsiveness.

--- End quote ---

I kinda wonder how much of that was early OSX just being so abysmally unresponsive that anything would have improved it massively, though.

--- End quote ---
By and large I don’t think “unresponsive” was something to describe Mac OS X. In my experience even early versions stayed way more responsive under heavy load than both classic Mac OS and Windows. (As a cooperative multitasking OS, Mac OS 9 felt very, very “snappy” under light loads, but under heavy loads it struggled.) For sure, versions 10.0 and 10.1 weren’t as snappy as 10.2 an onwards, when the graphics compositing engine (Quartz Compositor) was moved into hardware (Quartz Extreme).

Regardless, though, the point is that when you had an app that was CPU-bound, even if that app wasn’t multithreaded, having two CPUs meant one CPU could be entirely dedicated to that process, and all the app’s system calls, IO, user interface, and anything the OS or used wanted to do could run on a second CPU. In fact, this even helped if the app wasn’t maxing out a CPU, since reducing CPU context switches still improved performance on everything.

tom66:

--- Quote from: tooki on March 29, 2023, 07:46:45 am ---The only thing I’d say is that I do think that going from 1 to 2 CPUs almost always helps overall system performance, since one CPU can make sure system housekeeping and other OS stuff, background tasks, etc stay out of the way of your application, even if your application is single-threaded. (Fewer context switches.)

--- End quote ---

In particular, some modern CPU architectures influence OS scheduler behaviour.  The Ryzen processors for instance have 'fast' and 'not so fast' cores, which is a difference in the peak boost capability of any given core.  The OS tries to schedule tasks that are high utilisation on the faster cores, whereas interactive tasks (user interface, lots of I/O) go on the slower cores, to avoid context switching the faster cores. 

I did some tests at one point in my VM with compiling a build using G++10 on Linux on my 16 thread, 8 core Ryzen laptop.  Peak performance wasn't at 8 threads as many had predicted, but around 12-13 threads, though there were diminishing returns above 8 threads.  Once more than 13 threads were in use, the performance fell.  My guess is that the kernel will reschedule tasks using I/O onto the slower cores, whilst allowing other tasks to thread more effectively across the remaining 'actual' cores.  Although without diving deep into a timing analysis profile, it is hard to say for sure.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod