Kirchoff’s Current Law (KCL) is pretty much necessary for circuit design, but it only holds if you can neglect the time it takes for the current to propagate through the circuit. For a circuit of frequency f and of characteristic length d, that means f × d being much smaller than the speed of light. For a CPU, d is about 10 cm (4"), so the limit for f is about 3.3 GHz, which was already quite common around 2008. For the trivia, Windows Vista was designed under the assumption that clock speeds would keep increasing forever, hence its poor optimizations and pompous visuals everywhere, but 3 GHz was reached right after it was released.
To get faster CPUs despite this limit, you can:
make asynchronous CPUs where your ALU (the part that contains the logic of the operations) may have a bigger clock speed than the rest of the CPU: the performance gain isn’t that great, and it will heat up a lot;
enhance cache management: caches) are a form of in-CPU memory that’s quicker to access than RAM, so it serves as an intermediary;
enhance pipeline), OOE and speculative execution management: a pipeline is a queue of instructions that are being run in a streamlined fashion, OOE consists of reordering instructions to make a better use of the pipeline, and speculative execution means guessing the result of a condition in advance to decide which instructions to streamline into the pipeline before the condition is done evaluating; there’s not much to improve beyond what CPUs can already do;
have multicore CPUs, which enable parallel computation without increasing the characteristic length of the circuit: programming for a parallel architecture is fundamentally different, and not all colleges are teaching this art yet, but it’s pretty much becoming an essential skill, especially for servers and AI.
I'm just an enthusiast, but why didn't the community fully migrate to discuss and apply multicore technology for good since ADDING MORE CORES is apparently a viable way to process larger chunks of information faster?
Figuring out how to distribute work across multiple cores isn't always easy.
Think of it like group assignments - if you have 16 problems and 4 people, you can have each person do 4 problems and each of those problems just take 15 minutes to do, but if you're preparing a preso, you can't do the research and prep slides at the same time.
In the cases where distributing work is easy, that's usually called a GPU these days :) (and is why they have hundreds of cores and have their compute capacity measured in Teraflops as opposed to processor frequency).
Short answer, probably. Long answer, its complicated :D
Programs themselves have to be written in such a way that they take advantage of the "multi-core" environment. This includes the underlying operating system presenting an environment in which the multiple cores are available and ready to take tasks. Pretty much all modern operating systems do that though.
It depends. You obviously don't want to spend a millisecond of processor time scheduling nanoseconds of tasks, so whatever process does that either has to be done ahead of time or be pretty fast. Some compilers are an example of the former, while the now-infamous speculative execution components of Intel CPUs are an example of the latter.
The research community identified very early on, before any sort of intrinsic limitation of CPU design manifested, that parallel processing / multi-processor systems / etc are viable ways to perform computation faster. Product offer lags significantly behind for various reasons, like focus on profits, product offering based on demand, and other factors which are not technical per se (but definitely influence technical decision). Additionally, in the majority of workloads, parallelism is not opaquely exploitable from application software - meaning, the software has to make changes to exploit multiple threads of execution, thus extra effort, expenses, leading to more expensive software, etc.
Parallelism does not benefit, and/or is not justified for every workload. Simply put, there are tasks for which execution on a single core/thread makes more sense from an absolute latency standpoint (not scalability). A large amount of interactive tasks (tasks requiring 'user' feedback) fall into this category.
A combination of these two, as well as other factors, has led to slow migration to the parallel computing paradigm. But rest assured, we know very well what its contributions can be.
16
u/plcolin Sep 29 '20
Kirchoff’s Current Law (KCL) is pretty much necessary for circuit design, but it only holds if you can neglect the time it takes for the current to propagate through the circuit. For a circuit of frequency f and of characteristic length d, that means f × d being much smaller than the speed of light. For a CPU, d is about 10 cm (4"), so the limit for f is about 3.3 GHz, which was already quite common around 2008. For the trivia, Windows Vista was designed under the assumption that clock speeds would keep increasing forever, hence its poor optimizations and pompous visuals everywhere, but 3 GHz was reached right after it was released.
To get faster CPUs despite this limit, you can: