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

[alm]

We don't use PCs with multiple cores because it is a very efficient way, but more like because most of the alternatives (high clock, wider words) have reached there limits. The SW side is still limiting in how muliple CPU cores can be used. A 16 core CPU may not be any faster (maybe even slower) than a single core CPU if the SW does allow for parallel execution. The point is more than modern PCs go a bid overboard with just adding more cores that are rarely used.

What helps is that on modern computers there are usually multiple things running at any one time, unlike back in the '80s when multi-tasking was the exception. Now your average computer is running a bunch of browser tabs, likely a virus scanner, maybe playing a video, downloading a data sheet, etc all at the same time, so there's at least a bunch of processes that can be spread out over cores. And the high loads like matrix computations, simulations, games etc are generally optimized to use as many cores as possible efficiently.

[EPAIII]

IIRC, around the time of the Apple II, I was trying to find a way to get a single one into the budget of the company I worked for. I wondered if multiple users could use it at the same time from separate terminals, which would have been a great selling point.

Aren't dreams nice?

[DrGeoff]

so my question is why did 70/80/90 only have 1 cpu if cpus where so slow?if i understand most computer only had 1 single main cpu.
for example why it was possible use for example multiple Intel 4004
instead single main cpu to make faster computers.
if money was not issue,what would prevent 4 same cpus running in single system?

The CPUs weren't considered "slow" at the time. Any more than today's processors are considered "slow".

[coppercone2]

In the early days I would consider the lack of suitable software and the still existing complications in using more than 1 core for many problems as the large hurdles than sharing other resources. The other bottlenecks still existed and this was in part limiting the useful clock speed. So the need for a much faster CPU was limited. If needed there were often better alternatives to multiple CPUs to share the load.
A thing was more havine a dedicated FPU and the first steps towards graphics acceleration.

We don't use PCs with multiple cores because it is a very efficient way, but more like because most of the alternatives (high clock, wider words) have reached there limits. The SW side is still limiting in how muliple CPU cores can be used. A 16 core CPU may not be any faster (maybe even slower) than a single core CPU if the SW does allow for parallel execution. The point is more than modern PCs go a bid overboard with just adding more cores that are rarely used.

I would say given that the driving force behind computer development is corporations, that "have reached their limits" means that parallel computing was found to be slightly cheaper to develop in the short term based on financial analysis by the major players

Like how four screws and are not commercially viable compared to one screw and a plastic clip in that $500 ecu

Just going by what I know. And it might not have enough synergy with neural networks, I think we just decided its time to squeeze the mathematicians a little bit instead of all that touchy chemistry and EM problems. I noticed there is just too much heralding about parallel computation, it starts to feel like a sales pitch. And for the last like.. 15 years? there has been this massive push to teach people how to code and push them into CS, from grade school even. Well they don't know about making things faster but they can write code, so they will work on logical problems rather then physics problems.... they certainly mustered quite a big work force that is trained at solving those types of problems. Number of people encouraged to learn about optimization algorithms vs transistor EM physics/engineering. Lots of piggy backing of skill sets too, teach logic and it is supposedly applicable to numerous fields (for now).

Not that I disagree too much, because its frustrating as hell to wonder 'well why can't I put two of these together...' but I do wonder what kind of other things we miss out on, could be something real nice. maybe less downplaying of cascade failure scenarios would be a result?

[tooki]

I would say given that the driving force behind computer development is corporations, that "have reached their limits" means that parallel computing was found to be slightly cheaper to develop in the short term based on financial analysis by the major players

Like how four screws and are not commercially viable compared to one screw and a plastic clip in that $500 ecu

LOL no.

If you look at the history of computing, technologies tend to first emerge in extremely high-performance computing (HPC, that is, supercomputers and mainframes) and then trickles down. HPC is not nearly as price-sensitive as desktop hardware.

Parallel computing was, and is, done because all the other measures are at their technical limits. Clock speeds don’t scale cleanly. Word size doesn’t help with many things (I don’t think we will see 128-bit CPUs any time soon). Etc etc etc.

[tom66]

One of the biggest issues with multiple CPUs is maintaining coherency between different processors.

Cache coherency is probably the biggest headache.  If two threads are operating on similar areas of memory, it's possible that threads could have a different view of the memory.  This is important as most operating systems depend upon the fundamental idea of a processor-width data type being atomic, for instance x86-64 guarantees that 64-bit loads and stores are atomic.  So you need a mechanism to broadcast "incoherency" data across the bus to ensure that the caches know to flush invalid lines out.

The other issue is that in the 90's, CPUs used to be quite big, on 300nm+ processes.  Once an SRAM cache was on the die (which was far more important than multi-core functionality), there wasn't really enough space to fit additional cores and data-buses to link those cores to each other.  A multi-core CPU also needs multiple caches, as each core needs a local cache to give acceptable performance, whereas a single-core CPU at a lower speed might get away with a single larger cache.  The size is an issue especially for cores like x86 which functionally are very complicated, having long instruction words and pipelines.  It really was process nodes falling below 65nm that made it possible to have dual and quad core CPUs in consumer hands, and then once things fell below 20nm we see 8/16 core CPUs as commonplace.  Improved architectural design allows those CPUs to execute more than one thread per core with certain limitations.

Parallel computing also requires changes to the operating system and different approaches to programming,  programmers need to be familiar with the traps of multi-threading and things like mutexes, semaphores, thread-safe data structures etc., and operating systems need to have schedulers which can cope well with multithreaded programs (especially ones with a lot of I/O -- historically Linux and Windows both sucked at this, but improvements in the last decade have been noticeable, like Linux's CFS.)

[dmills]

As a teenager I wirewrapped a dual 68000 system, it was effectively a NUMA box and had each processor with its own memory space that could be read or written to from the other core at the cost of forcing a bus request/bus grant on the target.

Clock speed was IIRC 8MHz.
It worked, but then teenage me found out that I REALLY needed some locking primitives.

Would have been late 1980s or so.

[Codex]

Some did. The Z80 systems I worked on had multiple Z80 CPUs, one to handle all the communications, one to handle and manage the disk drives, another for Analogue IO and one for the general control processes.  You could use Z80 bus controls like ~BUSRQ to control the address and data bus (blocking) and so each CPU could have access to memory and IO.  Alternatively we used dual port memory, IO ports and interrupts to allowed each of the CPUs to run with almost no blocking. This was in the early 80s.

[ejeffrey]

The question is backwards, it's why do we have multi-core CPUs now.  Paralleling CPUs has a cost in terms of complexity and performance, and a *huge* cost of developing parallel applications to actually use them.  1 fast CPU is almost always better than 2 slower CPUs.

The 80s and 90s were full of startups trying to do something really clever, but most of them failed because it didn't matter what you did, you were going to get shown up by a new micro-architecture on a new fab process in 12-18 months.  That sets a very narrow window to make back your development costs before it is obsolete. 

Multi processor systems did exist, as everyone else here has pointed out, but in the mainstream market, people were busy adding things like caches, pipelining, multi-issue, vector units, out-of-order execution, branch prediction, and process other improvements that give orders of magnitude performance improvement for roughly the same hardware cost instead of adding multiple processors that could get you less than 2x the performance for a substantially higher cost -- well over double the cost for the processors themselves, although you didn't necessarily need to double the memory and IO.

What happened in the late 2000s and early 2010s was that the huge rush of micro-architectural improvements  had mostly played out.  There were still improvements to be made, but a good feature is one that gives single digit percentage increase in a handful of important workloads.  At the same time, process node improvements stopped producing significantly higher clock speeds, hitting a practical wall around 4-5 GHz.  Process node improvements however still continued to allow more transistors on a single die, and so the practical way to use them became multi-core CPUs.  For mainstream systems, multi-core CPUs improve a lot of the problems with traditional SMP that used multiple sockets.  The cores can share a memory controller and L3 cache, running fewer wide/fast buses off chip. They can also do fast and low-latency cache coherence communication between cores. You don't need multiple 1000+ pin sockets, and motherboards need no special design to support multi-core configurations.

[tooki]

The question is backwards, it's why do we have multi-core CPUs now.  Paralleling CPUs has a cost in terms of complexity and performance, and a *huge* cost of developing parallel applications to actually use them.  1 fast CPU is almost always better than 2 slower CPUs.
…

Great explanation.

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.)

But from there, the marginal benefits of each additional CPU drop asymptotically.

I remember this very clearly in the early 2000s when multi-CPU Macs finally made sense, since Mac OS X has real SMP support. Few applications back then were meaningfully multithreaded, but adding that second CPU massively improved system responsiveness.

[m k]

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.

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]

but adding that second CPU massively improved system responsiveness.

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

[tooki]

but adding that second CPU massively improved system responsiveness.

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

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]

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.)

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.

[mendip_discovery]

Iirc we had also just gone from mainframe PCs where you worked at a terminal to a place where you could each have a pc on your desk and there was a boom in sales from 95 onwards that meant the processors were getting faster and cheaper and we were mostly happy with the speed.

[Gyro]

Iirc we had also just gone from mainframe PCs...

An interesting concept!

The closest I got was a small PDP11 on a table, but that counted as a minicomputer.

[madires]

Sun SPARCstation 10 (also 20): up to 4 CPUs

[mendip_discovery]

Iirc we had also just gone from mainframe PCs...

An interesting concept!

The closest I got was a small PDP11 on a table, but that counted as a minicomputer.

I find it interesting we had cloud computing before it was called cloud computing. Then we all got machines at work and at home. Now we are going back to the cloud.

I started in computers when I was a kid with a BBC Electron, then a 64, Amiga 600 and then a 486...I am almost 40 so not as old. But I know types that do the whole 4 Yorkshiremen sketch when talking about computers. "You were lucky to have punch cards, we had to move valves and relays" "pah valves, young whipper snapper when I was a lad..."

[Gyro]

I am one of those Yorkshiremen, in both senses. I started out on an ICL1902... with punched cards!

[RJSV]

   To help answer that, you need to think like
'Its 1978'.
   Culture, man, culture.  A 'multi-CPU' system was, virtually, almost a joke...like 'Flux Capacitor'.  That's because it was new and exotic, and somewhat 'unnatural' sounding...like a two-headed lion would seem.
Folks that were in the know could dream, lazily into a good cup of coffee (going nowhere), while the truly ignorant would outright dismiss multi-cpu layouts as, well,...unnatural, but I repeat.
   Meanwhile two things;
   Folks designed and built separate systems, each with traditional single CPU controller, such as the hard disk storage.
   Secondly, the true multiples really took off (IMO) with gaming system stimulus, including also the overclocking.

   The 1978 tech culture was just getting used to an APPLE Computer on the market and in the news.  Teachers started doing heads-up, maybe computers would be popular...yes?
Memory chips avail speed and price was a huge deal, and many, many of us didn't have the orientation and focus, on that one aspect, of architecture...barely flowing the idea of having ONE CPU running things all day.  (Computer could do your taxes, but then what ?).
   People had enough mystery just considering using a single CPU.  In 1978, that was still a few years, before the '1 MHZ' barrier was, practically, met in home systems. Commodore64 was approx 1 mhz, but that was a few years, still, 1983.

[tooki]

   To help answer that, you need to think like
'Its 1978'.
…
   People had enough mystery just considering using a single CPU.  In 1978, that was still a few years, before the '1 MHZ' barrier was, practically, met in home systems. Commodore64 was approx 1 mhz, but that was a few years, still, 1983.

As I said before: the OP doesn’t even specify “personal computers”, they just said “computers”, and there were already various multiprocessor computers in use. They just weren’t home computers.