How CPUs do Out Of Order Operations - Computerphile
Вставка
- Опубліковано 22 тра 2024
- How CPUs that are capable can manage to complete tasks simultaneously without the program knowing. Matt Godbolt continues his series on how processors work.
Many thanks to Space Potatoes for kind permission to use their music: 2020rendezvous.com/
/ computerphile
/ computer_phile
This video was filmed and edited by Sean Riley.
Computer Science at the University of Nottingham: bit.ly/nottscomputer
Computerphile is a sister project to Brady Haran's Numberphile. More at www.bradyharanblog.com
Thank you to Jane Street for their support of this channel. Learn more: www.janestreet.com
A better example than a sausage factory, is a film production, all the scenes are filmed out of order, based on locations, crew availabilty etc..
But as long as the editing is ordering the scenes in the script's order (program) the result for the viewer will be acceptable
Nice analogy!
Let's throw branch prediction into the mix.
You have two units, each filming different scenes that take place at different times in the movie.
Director/writer/producer make a script change, now the second unit has to re-record a new scene and disregard what they already filmed.
Ah, we'll just fix it in post, right?
I see folks are speculating on the topic already ;)
And the people posting "first" ? " second" are displaying...out of order ;D
hiii Mat, thanks for Compiler Explorer... i really love it. u r my inspiration
Your puns, much like nearly all of your talks and tools, are great 👏
The whole time you were talking about "as long as nobody notices", my brain was going "Spectre! Spectre! Spectre!" So, nice that you did indeed point it out at the end.
I find it hard to explain to people who are technical enough to understand a little bit, but not deeply technical, how it is possible that the same bug existed in essentially every mainstream CPU on the planet, including both RISC and CISC ones, both big (e.g. POWER) and small (e.g. Cortex) ones, in Intel and AMD and Apple silicon, among others. And the answer is that it exploits one of the fundamental "tricks" that make *every* CPU fast, which is basically the trick you are explaining here.
Of course, this is only the beginning as the new Go.Fetch vulnerability has shown which exploits data-dependent prefetching.
WAIT WHAT THE FUDGE YOU ARE THEEE MATT GODBOLT!! WE HAVE A CELEBRITY OVER HERE OMG
Bonus points for a Winamp reference. Topical too since the source code is being released in September!
It really whips the llama's....
What really? Why they release it?
It's crazy how Tomasulo's algorithm for out of order execution was was first used in the IBM System/360 Model 91 released in 1967, predating the integrated circuit.
We stand on the shoulders of giants.
Simply brilliant. I would highly suggest covering Intel's "Itanium" CPU, and why it went awfully wrong.
Hang on, I know that logo on the shirt.... is that...? Yes, it IS Godbolt!
Men of culture, we meet again.
Love me the robots where W == waiting and W == working.
Yeah... I didn't think that through properly did I. Last minute changes never a good idea. Hopefully you get the idea though?
I was waiting for P to go from processing to paused.
@@MattGodbolt Always allocate at least two bytes to your status strings 😉
@@IceMetalPunk Strings? How wasteful.
What you need is an enum. 0 = empty, 1 = ready, 2 = waiting, 3 = working, 4 = completed, 5 = retired.
Only 3 bits needed (with a couple of statuses to spare - I already used one to represent "empty", as a null reference to say "ignore this row, as we've not filled it out with data yet". And if we need a human-readable string then we can have an array of strings: ['empty', 'ready', 'waiting', 'working', 'completed', 'retired'], using the status as the index.
And you don't need the English language to start all the words you want to use with different letters at any point.
@@klaxoncowthis is why the high level language Devs don't get much respect. They are severely lacking in fundamentals because they generally just know how to make a website.
please, please more cpu videos....
Agree! Low level, hardware related videos are awesome and very valuable!
This series has been fantastic so far!
The times where a sqrt would take 100 cycles are long gone. These days it's more on the order of 16-20 cycles. Still slow compared to a multiply or add but in the ballpark of a division.
20 cycles is still enough time for ~100 instructions to pile into the ROB behind the sqrt at typical pipeline widths (plus whatever was already behind the sqrt when it started executing).
Modern x86 CPUs will have a RISC kind of pipeline in the microcode level despite the base ISA not implying such pipelining.
So to answer the main question, technically the CPU is doing (N core * pipeline phases / average cycles per instruction) things all at once, but that's not a neat answer since hyperthreading is possible and not all instructions run equally as latency from prediction rollbacks, cache locality/coherency, and write interference need to be considered, among many other things.
N cores * issue width * average micro ops per instruction (max execution units) etc. etc. hundreds of limitations.
This concept of RISC/CISC is an outdated idea. All modern CPUs are implemented using microcode, which is technically RISC and on top of it we have a CISC ISA, they're all hybrid . Yes, even the simpler ones like those who use RISC-V end up having even smaller microcode for implementation, its just convenient.
@@monad_tcpI wouldn’t consider microcode a type of RISC since that layer typically isn’t exposed at the programmable instruction level and only microchip designers who are working with something like Verilog actually use that level of coding.
MIPS exposes the pipeline as branch delay slot. RISCV kicked it out again. We are back at 8086 like ISA. MIPS already hid any data hazards of the pipeline and would rather wait for the cache or main memory.
Ah, you mean that a load instruction is kinda the start of a pipeline. Next comes a compute instruction. Yeah.
There isn't a fixed number of pipeline phases.
Thanks so much for these videos. Matt is truly a great teacher of these concepts!
Thanks Computerphile, I've been loving these series on how CPUs work. Absolutely fascinating, even for a layperson like me
"Well I feel like this is a i don't know if you've ever watched Qi where the big bell goes-"
*"BRRRRRRRR"*
lego can do almost anything
@@RecycleBin0 It's GR8BRIK's old logo
Years later someone finally explaining the Spectre / Meltdown bug properly. This is why software mitigations make the CPUs affected much slower: they limit if not disable entirely this kind of mechanism.
As a web dev, this reminds me a ton of database transactions. You can update many columns in many rows in a database table at once, but if one fails, the transaction fails as a whole; it's "undone" because the changes never get committed to the database in the first place.
What is above, so is below. What is below, so is above.
Very nice episode! Great explanation with the todo board 😊. A great follow-up would be how modern CPUs prevent specter-like attacks, because i assumed the cache would also be reset after branch prediction failed.
Coding assembly on the first few Archimedes machines was very interesting, multiple logical options with instructions (like conditional execution and barrel shifting).
This really kicks the llamas ass.
Well and truly kicked indeed
Jump instructions have entered the chat
😂
I know Goto when I see their alt!
14:31 "Honey, why are you shouting'Pee! Pee!' into your phone?"
"No, mum! I'm shouting 'p' _at_ my phone."
"Well whatever it is you do with pee and your phone, it is rather odd, isn't it, and I'd prefer for you to do it in your room."
thanks for mentioning spectre at the end :)
Amazing video ❤
This something you don't generally need, but when you do need it it's very useful to have. Had a bug the other day in an embedded system where the file system chip would put data on the bus despite its driver never asking for it, because an RSA calculation somehow triggered a speculative read in the chip's DMA region. Debugging was infuriating, 'cause every time you'd change some code to do an inspection, or would even interfere with a debugger, you'd interfere with the pipeline causing the bug to disappear. Only reason we ended up finding the solution was due to some very kind and skilled people in some forums all over the internet and an erratum for the chip
Parallel processing can be "fun" to debug. I once had an exit process that started failing. It ran perfectly in debug because waiting for me to respond to the prompt gave the parallel clean up process time to complete. My fix was a bodge: I shuffled the order of my code till it worked. My best guess as to the cause of the failures was that a release of the compiler or operating system had done something to the timings.
@@andrewharrison8436 been there, done that, joined the club, got the t-shirt.
At least it's a problem you can solve with some semaphores though...
That said, the feeling you get when you actually solve an issue like this. Very satisfying
Love the compiler explorer. :)
I like the desktop background - where's it from?
5:00 - I think the first to do "pseudo-assembly" was Knuth with MIX. Though, his "pseudo-assembly" was perhaps more rigorous than what you intended.
Do modern compilers produce machinecode that help the CPU with this process? A sort of preprocess, so less stuff has to be undone?
Where can I get such a cool compiler explorer hoodie?
btw: great tool, really love it!
I remember from a computer engineering course long ago, that there was a branch "prediction" scheme with superscalar processors where the prediction part was skipped altogether. Because the processor was capable of doing multiple things at once, it could just process both branches simultaneously and throw out the one that wasn't needed at the point when the branch was finally processed. I don't think it was actually ever used and if it was then not much because actual attempts at prediction are still better in most cases.
Some GPUs actually do this! They run hundreds or thousands of threads over the same code, but execute groups of threads in lockstep, so if a group of threads encounters a branch and they don't all take the same path, they will all run both branches and then mask out the results from the wrong branch. It's basically a way of fitting branching into a SIMD pipeline.
One nitpick on the description of the "retirement" stage you described, and I apologize as I realize it may be a detail intentionally not visited here. While it is simple to say that it goes down in order committing things back out of the cpu, it only prevents committing if there is an unresolved conditional branch before the instruction. Things otherwise can commit back to main memory or cache out of order, and is one reason that atomics use acquire/release semantics to assert control over the ordering.
It's amazing what can be implemented using logic gates etched into silicon.
No Byte Bug puzzle here? Jane Street has addressed today's Numberphile BugByte puzzle 1-24 as Computerphile puzzle.
src="/static/img/new/computerphile-puzzle-2024.png"
How is it writing values to that table, then checking those values to see if it's ready, without going through at least one clock cycle? How are they managing synchronization?
I guess if you throw security considerations into the mix, things quickly become super complicated ;)
Nice vid about cpu internals 👍
Winamp, it whips the llamas ass! ^-^ What a blast from the past.
Let's dive into Very Long Instruction Set computer architecture (Intel's Itanium and Multiflow's minisuper) where the compiler from it's analysis determines which instructions run in parallel together. simplifies the pipeline.
Interestingly for concurrent programming, out of order operations like stores can be visible to other threads since the pipeline executor won’t have visibility into what another pipeline executor is doing.
It very much depends on your CPU architecture. X86 makes some pretty strong guarantees (for normal load and stores). And speculative stores shouldn't be visible to other threads under any circumstance that I'm aware of.
So, mentioned at the end of the video were issues that sounded like they might affect timing. (eg, something unexpected was in a cache, or got bumped out of a cache.) However, how do you account for actual memory side effects? For example, there are some chips that automatically advance an address on reads/writes. How do you ensure that access to such a chip is strictly in order, with no speculative/out of order access?
You only write at the retire stage (writes are in order) and you cache "writes" to another buffer so that out of order reads get the right result at the right time. Beyond that, cache coherency protocols keep it safe between processors.
That is to say, you cache out of order writes before retirement locally, so that out of order reads see the correct values and don't need to wait for writes to retire.
Which area of computer science is this? Where can I learn more about it?
Also, what is this topic called? Out of order operations? Again, where can I learn more about it?
Google and literature piracy
I just learned not that long ago, that Cray computers invented a lot of what you were talking about in this video. Multiple streams, pipelining (not the idea, making it better), out of order execution, et al. It's why Cray was able to hold on to the title of supercomputer for so long. They were doing things nobody else at the time could. And now it's part of pretty much every modern processor. It was a heady time.
it was a Crayzy time
For much of computing history, microcomputers (i.e. Intel+AMD) followed the lead of mainframes (i.e. Cray+IBM).
Modern NASes allow the user to hot-swap hard drives. Back in the 1970s, mainframes allowed the user to hot swap CPUs and RAM. I still can't do that in an AMD64 system in 2024.
I can see how Cray multicore systems could schedule a process across multiple cores, but I don't think it is the same as multicore CPUs of today. Memory access and caching would be significant in an SMP way. At the processor level you can take advantage of shared L1 cache on a single thread. I think Cray was more about distrubuted threads, but each thread wasn't context switching.
What's interesting to me about this is that it suggests that the core of a CPU could get into a deadlock lower than potential software dreadlocks between threads.
In a single cycle, modern CPUs are performing thousands of XORs in parallel for every cache line check and can do this in parallel for each of the instruction, data or address translation caches. So, the answer should be thousands.
CPUs are actually much faster than in this example. They can see ahead of time that you are squaring the numbers, so there is no need to square root at the end. The robots inside the CPU are probably trained with captcha as well, which is still legal when this comment was written
once heard jim keller talk about this in an interview. Kinda insane what's happening in a cpu nowadays.
So what's the Apple M3 & raspberry pi 5's biggest weapon?
Obviously when the branch prediction fails, a lot of these instructions need to be thrown out and redone, but is there anything stopping a CPU core from taking instructions from both branches, adding it to this out of order table, and letting both get executed until it knows which branch is taken and can evict all of the instructions from the wrong branch?
Given you'd have to create a new instruction stream for every branch you see, and how frequently you come across branches. You'd end up needing a huge amount of instruction streams that are nearly all going to be discarded. The cost of adding all these streams is also gonna be very high and cause bottlenecks.
To help the throughput when there are branch mispredictions CPU vendors created things like hyper threaded cores, where if one stream of instructions has a mis predict, the other stream will have less contention for execution units so likely be able to run a little quicker
I thought this a while ago, and realized that it would fail pretty quickly, just based on how often branches happened. The real issue is that the processor is already so much faster than the memory, that the memory is the weakest link here, not the processor. If you tried to fill both branches of the pipeline, that's twice the memory bandwidth.
If it's all in cache, you might be okay, but can you guarantee that? You cannot.
Especially when your pipeline is as deep as it is in modern CPU's.
What you're describing is predicated execution which tend to happen a lot in vectorised computing and pipelines, think SIMD or GPUs, where both sides of a branch are executed but only one side of the branch is kept at a time. An advantage of this approach is that you get to keep the speed boost of vectorised computing, but at the cost of reduced throughput as extra code is ran.
If you're interested in learning more, you can read "Conversion of control dependence to data dependence" for one of the first places where this idea was introduced and fleshed out, or for something more modern, give "ISPC: A SPMD compiler for high performance CPU programming" a look over (or any other modern day SIMD tutorial. Most SIMD these days come with instructions purpose built for this kind of predicated filtering)
@@jeromethiel4323branch prediction also fails pretty fast based on how often branches happen. Or is there some “bunching” of successful predictions?
Usually successful predictions happen in a row. 99% hit rate looks more like 1 million hits followed by 10k misses than 100 hits followed by 1 miss.
Great, but what happen to the pipeline when an interrupt occur (like syscall or time slice expired from OS)?
An interrupt is basically a jump with some extra steps to save the current CPU state and switch to a new context, so I imagine it has to go through the pipeline just like any other part of the program. Whatever is currently in the pipeline may either finish going through or be discarding depending on how interrupt handling is implemented.
Thank you.
Remember the early days when XBox programmers slated PS3 CELL because it was 'too slow?' It took a while to shake off the old way of doing things and really jump on board the idea of parallel computing. Are modern x86 processors able to handle true parallelism these days or have they simply had to bodge something extra onto what is ancient architecture?
If this paralelism is integrated, does the bend language achieve anything?
Compilers can do larger scale things, and discard operations altogether, which is way harder on this level.
To this day, I STILL use WinAmp.
Best music player ever.
You just know he chose a whiteboard because he was under the illusion that he'd just erase the old values in the cells instead of making a complete mess by repeatedly crossing things out 😄
Is it possible for a processor to calculate both branches of a branch?
yes, and I think I've read some cpu archs doing that... might have been itanium, but I'm not sure. It's wasteful, though.
What is his purple buffalo desktop wallpaper image?
It's one of the default Ubuntu ones; a Minotaur I think?
@@MattGodbolt Mantic Minotaur 23.10
He'll want to upgrade that before too long, doesn't it go end of life in a few days?
When a machine is out of order it needs to get fixed. C.f. the Spectre and Meltdown bugs.
7:12 but can't this example be implemented with a fused-multiply add and a hardware square root instead...?
It’s only a model
The CPU he is emulating doesn't have that, no
you might as well have a single instruction that calculates distance. It's just an example.
Is there a video of how alu does barrel shifting ?
several ways, depending on the number of bits/word. Easiest way is lookup table.
If you have a bunch of registers of the input shifting 0 bits, 1, bit, up to 32 or 64 bits and then just select from the one you need you've got a barrel shifter. It's simple but it obviously takes up a lot of area.
@@user-qf6yt3id3w I know how that works ! But how’d you implement that in pure logic ? , just try designing an 8 bit barely shifter with logic gates and multiplexors, it gets crazy complicated
@@AnotherPointOfView944 lookup table is cheating 😂
@@VandalIO On an IC the wiring is not too bad because you can run the bit lines diagonally. Obviously you can't get around the fact that an n bit barrel shifter needs an n*n array of cells. Or even 2n*n if you want expanding shifts which is handy in graphics.On the other hand the cell doesn't need to be a flip flop.
Actually if you read the Wiki article there's a better way to do it which is better for wider devices"
"The very fastest shifters are implemented as full crossbars, in a manner similar to the 4-bit shifter depicted above, only larger. These incur the least delay, with the output always a single gate delay behind the input to be shifted (after allowing the small time needed for the shift count decoder to settle; this penalty, however, is only incurred when the shift count changes). These crossbar shifters require however n2 gates for n-bit shifts. Because of this, the barrel shifter is often implemented as a cascade of parallel 2×1 multiplexers instead, which allows a large reduction in gate count, now growing only with n x log n; the propagation delay is however larger, growing with log n (instead of being constant as with the crossbar shifter).
For an 8-bit barrel shifter, two intermediate signals are used which shifts by four and two bits, or passes the same data, based on the value of S[2] and S[1]. This signal is then shifted by another multiplexer, which is controlled by S[0]"
Depends on how many hardware thread cores it has. RISC-V calls these harts.
I wonder why there isn't "Don't predict this branch, or predict it THIS way" for security.
"I'll give myself infinite registers." - hold every possible outcome and just keep paying the memory wall tax. Now it's a physics problem.
Wait.... We can't pack them close enough to use this solution. Nevermind. I just moved the memory wall to everywhere and introduced a singularity to the least efficient solution. My bad, guys.
@@ScottLovenberg See also: SSA form, example: spir-v.
I'm usually lost about 45 seconds into these videos. Still love 'em, though.
Hey, just read the entire "Computer Architecture - a Quantitative approach" and you will understand!!!
Interesting that Itanium tried to move this complexity out of the CPU and into the compiler, but ultimately keeping this stuff in the hardware (x86) won.
My computer does 3584 instructions at once. GPU SIMT magic.
What does he actually mean when he says he has 4 CPUs on his laptop with 10 Units each?
Hate these kind of questions because they are never specific enough. Eg, he says in the 80 computers did one thing at a time. Reading bits out of memory still was 8 at a time.
He’s talking about one clock cycle
Bit logic is a Vector Computer Right there. Archimedes had a 32bit ALU in 1987. And 32 bit memory bus. 68k had 16 bit in the 70s, but needs 4 cycles for everything.
Depends on how you define one thing... 8bits OR is it one byte...
❤
Square root is a one tick unary operation as fast as an add. Common misconception. Trig instructions are slowest on modern CPUs
The answer to the question changes based on definition.
If you subscribe to the notion that computers can do as many things as there are cores in the system, then computers can to thousands of things every clock cycle. Assuming the computer has a graphics card with that many cores.
If you also subscribe to the notion that each core does many things at the same time on every clock cycle, well then you have many thousands of things happening every clock cycle.
And if you then look at a "super computer" (a rack of computers all tied together) well now they do millions to billions of things, billions of times per second.
But realistically, computers (doesn't matter how many cores they have, how many memories they have, how their pipelines are set up) can only really do ONE thing per clock cycle.
At the end of the day, there NORMALLY is a single INPUT and a single OUTPUT. You can do one INPUT every clock cycle and you can do one OUTPUT every clock cycle.
Yes, there are many cases where inputs and outputs are completely separated from each other. They don't cross communicate in ANY way, they could just as well be separate computers doing separate things. But then i'd argue that you should have asked "how many things can N number of computers do" and the answer would be N things.
So WHY can't many inputs and outputs be handled by a single computer at the same time, all the time? Because the inputs and outputs, somewhere in the process, needs to "talk" to each other or the operating system or a shared storage or the network. Once they do, they are bottlenecked by that interaction.
Just because a modern computer can work on many different tasks at the same time, it still isn't truly completely parallel.
The universe is truly parallel, there are no bottlenecks in that sense. So are, i would argue at least, quantum computers. Digital computers are only multitasking MID process, but at the end of the day everything comes together at a single input and output point.
If a CPU had two cores, it means it has four threads, which means it can do 4 things at the same time, right? Would it mean the CPU accepts 4 inputs and with 4 outputs?
A computer can simultaneously display a cursor, rotate its fan, make a mouse click noise, stimulate my retina, heat the room, annoy the cat, support a geranium, etc...
@@landsgevaer In a time slice...
@@bity-bite A CPU can have 1, 2, 3, 4... cores.
Doesn't matter though because it still depends on definition.
I see each core as a separate computer.
If you go to the microarchitecture level (as suggested in the video), a single CPU core can do as many operations as it has processing units for. If you go down further to the transistor level, a CPU can do millions of gate operations at once. It all depends on what “things” you’re counting.
Winamp!
It really whips the lamas ass!
And it's now going "open sauce" (sic).
still using it
OMG I suddenly miss Winamp!
Why don't compilers do this with cpu cores to automatically make every program multi-threaded? Too much overhead?
There is actually some research into "multi-core single threading", but as far as I know it never got anywhere.
The problem is branch prediction. Unless you are running and calculating real values you cannot do branch prediction at compiler time.
This guy has 4 10-core CPUs in his laptop
I wonder how much higher level scripting languages benefit from this. Presumably a fair bit as the interpreters are mostly just C programs…
Spectre and Meltdown want to fight!
Before watching, Speculative computation?
That's an acceleration method, they will probably talk about how CPU aren't really multitasking, just assigning cru cycles to different tasks.
RIP Winamp.
Nope. It's being released as open source (recent news!) Expect it to reappear soon!
24 Sep 2024 is the announce release of the source!
love the QI reference lol
26th?
7:07 For the game example you gave this would actually be way more than you need. Just multiply √0.5 against t1 + t3 and you'll get a close enough (if not exact) result. √0.5 just needs to be done once at the start of the game and stored for later use.
Computerphile would never air on UK TV, it's way too smart for the TV broadcasters these days
The correct answer is one. Just because multi-core CPUs can do more than one at a time doesn’t change that because they’re really just multiple CPUs with some shared resources, on the same wafer. It’s a more compact version of multi-processor motherboards. Each core is a CPU and doing one thing at a time. We’ve bastardized the meaning of CPU for simplicity when it comes to multi-core chips, but logically they are not a single unit, they are multiple units working in tandem.
Well he said computer not cpu
Isn’t it interesting how you can lock() an object in Java on one core, and the other cores respect this despite the widespread use of cache? How did that work with CPUs, like the two SH2 in SEGA 32x? Jaguar and PS3 cell only have scratchpad memory. JRISC in the Jaguar can access shared memory, but lacks instructions for locks. I think that it was not allowed for two of the 3 (4) processors to write to the same object . Only producer, consumer pipeline was allowed. So, in a queue each party only writes to their pointer: read or write. Each party reads the other pointer to check if the queue is full or empty.
You can only write to a RAM cell from one source. The bus gets locked. CPUs have had a test and set instruction basically forever.
The instruction locks the bus until complete.
Locks in high level languages mark that team cel (logically) as volatile which forces the view on the CPU to skip the cache and go out to the memory every time to ensure the lock can be acquired.
As a result, locking has greater overhead and has greater affect than code that doesn't require locking/semaphores. Locking hurts parallelism too.
As a result, in recent years, there has been a fair amount of work on basic data structures and the like that can be implemented without locks to address the pain of locking and scalability.
@@nathanbolstad9567 volatile in C just prevents that the value is „cached“ in a register. A binary compiled for my 386sx doesn’t know about cache. Only thing is that writes to video ram or sound queues are so large that it flushes any write back buffer. X86 has ports to signal that the value has to go out.
Quake light maps were calculated on a 4 CPU Pentium board. No test and set instruction.
So like on game consoles of the time lockless data structures were common. Amiga broke the 68k TAS instruction because the blitter and the CPU were never supposed to write into the same data structure.
Damn, winamp
Ah, so cpus do a few calculation (multi-cores) at once, and gpus do thousands of operation at the same time. Got it, I think. 😁
ahh, winamp.
He’s cute
Instead of two inputs, I'm sure a computer in the future will handle three inputs. Something like 1 + 2 + 3, That would be awesome.
Three-operand instructions are as old as x86 is with LEA being the earliest and most important among them. Most vector instructions nowadays take 3 operands as well, so that a separate destination register may be specified.
21:34 Of course we notice - branch prediction uses more power and generates more waste heat. It can also rip nice holes into your cyber security.
It angers me to state all that in the first place.
Has a whiteboard which is easy to wipe, still crosses out all the old words...........
AI will bring back VLIW.
what makes you say that?
@@KingJellyfishII efficiency. There is cost to figuring out operation order, and doing it every time is not as efficient as at compile time.
CPUs have a little higher frequency than 2-3 Ghz nowadays...
Not much higher. I think the record was set at 5.5GHz back in 2012, but most processors are still in the 2-4GHz range due to problems with signal propagation time and heat generation when running at higher speeds.
@@trevinbeattie48889117.75 MHz Intel Core i9 14900KS earlier in March.
@@trevinbeattie4888and what if we would take a RISC core from for example the PlayStation? It is tiny. Run those at the high clock and spread them along the edge of the die to get rid of their heat. The rest of the chip is slow cache.
@trevinbeattie4888 maybe that's an average overall but desktop pc cpus are between 5 and 6ghz across the board.
@trevinbeattie4888 and what is the point of bringing up a record that is like stock ac clock of current i9
Computers are stuck at 2-3 GHz? Huh? More like 5-6 at the high end. Even laptop chips can clock above 5 nowadays.
That's still just a multiply of 2, whereas parallel execution can multiply by way more.
@@solhsa yes, I’m well aware of that. I use parallel computations basically every day in my scripts. They can be a pain to write, they eat a lot of ram, and they can be crazy fast if you don’t run into some other bottleneck like memory or storage i/o. But stating that CPUs are stuck at 2-3 GHz is just factually wrong, because they aren’t. My 7940hs can reach 5 depending on the workload and my 13700k runs above 5 GHz at stock.
Third?
first LOL ?
nope second :P
Please use the correct terms for things you are explaining. Like, don't call a processor that has more cores than one a computer with multiple CPUs. The computer still has one CPU that contains multiple cores, which individually are hyperthreading the instructions. Not naming things correctly or at all makes the thing you explain very hard to relate to other information that one might have on this topic. Therefore people will learn less because they can't connect it. Naming cores CPUs makes people who already what you are talking about either confused or suspicious of your research. PLEASE just name things the CORRECT way. Otherwise the main part of this video is better than the beginning, thankfully
the problem is that "CPU" is quite an ill-defined term. Most people use it to refer to the chip or even whole unit that contains one or more cores, but by a computer science definition each core is in fact its own CPU. It's simply an inconsistency in naming between the "layperson" and the "academic", for lack of better words.
Please backup all your videos to a github repository for the day UA-cam goes extinct or otherwise has some kind of wipe
Then the risk becomes github going extinct or getting wiped.
"How many things can a computer do at once?"
0:22 "only once"
1:15 "how many things can it do at a time? and again you might think: once"
I feel like I'm having a stroke here. Why do you think "once" is a valid answer to "how many AT ONCE"?