Yeah, me and Benny worked hard to make concept designs and test them then show you how there made so he told me he’s taking a break for a bit to get more info
Hey ben meister, I wanted to thank you so much for your videos. You got me into programming all those years ago and I loved your videos so much, they taught me so much and you're so easy to pay attention to. I miss them a lot and was wondering if you would make more? I get if you don't and if you don't then thank you so much for setting off the spark that is now is hopefully going to get me a job that involves programming in the air force. Thank you
This is awesome. Each time you post a video about this new computer I discover another feature that will make it awesome. Everytime you add something it feels so good, it works great, ... I wish I had the english words to describe it better. You did amazing, as always!
Sorry for what happened that day, I swear I wasn't trying to spoil your video, I just got a little bit excited for meeting an old redstoner, I hope you don't hate me.
Could you show us how multi-core CPUs would work after this series? I'm wondering about the distribution of instruction management between the CPU and programming; what does the CPU need to control? What does the programming need to control?
Although interesting, multiple cores aren't really the next logical step in a better microarchitecture. There are a significant number of other microarchitecture improvements you can make that will have much larger performance implications than multiple cores. To give you an idea, I like to use the history of Intel's microarchitectures as a rough (but surprisingly accurate) guide to what stages which techniques make sense: 8086 - 0.33 MIPS - Minimal working CPU at minimal practical bit width 80286 - 1.28 MIPS - Separate memory bus and memory management circuitry 80386 - 2.15 MIPS - "Goldilocks" bit width, microcode, and usable math coprocessor 80486 - 11.1 MIPS - Pipelining & Caching Pentium - 100+ MIPS - Superscalar architecture, Branch Prediction, Microcode control over pipeline and superscalar features, separate code and data cache, simple vectorization (MMX), combinatorial multipliers, loading multiple instructions/data simultaneously Pentium Pro - 541 MIPS - Out-of-order execution, level 2 cache, pre-loaded instruction pool, pre-decoded microcode, speculative execution, superpipelining, register renaming (Pentium 2 & 3 used same microarchitecture. Pentium 3 was 2,054 MIPS) Netburst/Pentium 4 - 9,726 MIPS - Simultaneous Multithreading (or "hyperthreading"), "Quad-Pumped Front-Side Bus" (basically meaning ways to read huge amounts of data from RAM at once), Micro-op cache (not dedicated, part of L1 cache), near-optimal branch predictors, maxes out sheer clock speed. Core microarchitecture - Dual-core is 27,079 MIPS (13,539.5 MIPS/core), Quad-core is 49,161 MIPS (12290.25 MIPS/core) - Multiple cores (finally!), level 3 cache, more efficient decoding, better caching algorithm, more efficient bus usage, dynamic clock speed, hyperthreading is REMOVED for some reason (it is re-added later, not sure why Intel removed it here) Based on those guidelines, the CPU from my original series was somewhere around the "8086" level, and the CPU from this series should end up being around the "80486" level (although I'm doing a few things from the "Pentium" level, like vectorization). As you can see, there is a small universe of various improvements to be made before you get to multiple cores. If you think about it, it makes sense: Multiple cores at least doubles the circuit size and complexity, yet only improves performance if you have more independent threads of execution than a single core can keep up with. That improvement is actually even less than you'd think, since even ignoring the fact that it's very hard to get the balanced load of independent threads required to take full advantage of multiple cores, a single core can do a surprisingly good job of keeping up with several threads of execution when it has simultaneous multithreading. What all those "intermediate" optimizations are attacking is instruction level parallelism, meaning different instructions within a program that can be executed simultaneously. That's a much juicier target for performance, because of this: In software, the most performance critical code is in loops, and loops have, quite literally, *infinite* potential for instruction level parallelism. That's how DSP's get such great performance (compared core-for-core, cycle-for-cycle, a typical DSP is almost precisely 2x as fast as the highest-end x86 processor on the market, and at 1/10th the power consumption): Because of the more restricted domain, they can take far better advantage of instruction level parallelism than conventional processors. Another example of this is in the chart I just showed you: The biggest difference between 80486 and Pentium was the better instruction level parallelism from superscalar architecture, and that resulted in a nearly 10-fold performance increase. In contrast, adding multiple cores lead to a much more modest 40% improvement per-core, and even being unfair and not doing a per-core comparison, it's still only 5x (It's unfair because the numbers assume that all cores will be fully loaded at all times, which as I hinted at earlier, is not even close to true in practice. If you want to see for yourself, pull up your system monitor and see how often all your cores are fully loaded. Unless you're doing a task that's specifically optimized to utilize all cores, the answer is probably "almost never") Bottom line: Given the choice, by far the best way to address CPU performance is with instruction level parallelism optimization, not multiple cores.
ALU, registers, cache all designed and bused vertically. Ram is using the same buses as the cache but the inputs and outputs, encoding and decoding, are being done horizontally? This doesn’t make a lick of sense to me what am I missing
Hey Benny, I just discovered you're still alive, coming from your programming channel, and I was wondering whether you have any idea when you will be returning to thebennybox?
Ryan Dupuis You should check if ur furnaces are the right power or if all pieces of redstone are placed or if your comparators are in subtract mode when needed
Hey Benny, like Timo I've found your programming videos extremely useful and would love if you could go back to it, I'm still subscribed to thebennybox:)
The Bob Ross of Minecraft redstone?
I dont really understand all of this crazy stuff but all I know is that it is a very good video. Keep up the good work!
Yeah, me and Benny worked hard to make concept designs and test them then show you how there made so he told me he’s taking a break for a bit to get more info
Hey ben meister, I wanted to thank you so much for your videos. You got me into programming all those years ago and I loved your videos so much, they taught me so much and you're so easy to pay attention to. I miss them a lot and was wondering if you would make more? I get if you don't and if you don't then thank you so much for setting off the spark that is now is hopefully going to get me a job that involves programming in the air force. Thank you
This is awesome.
Each time you post a video about this new computer I discover another feature that will make it awesome.
Everytime you add something it feels so good, it works great, ... I wish I had the english words to describe it better.
You did amazing, as always!
God damn it Benny!! Now I have to tear it down and rebuild again, damn damn, damn and damn again. Least I know how it works lol
We miss you on thebennybox! pls come back :O
Sorry for what happened that day, I swear I wasn't trying to spoil your video, I just got a little bit excited for meeting an old redstoner, I hope you don't hate me.
ahahah
You're fine :) You've caused no trouble at all. Really, I don't think you or anyone will unless they're really trying to.
Thank you Sir :D
Could you show us how multi-core CPUs would work after this series? I'm wondering about the distribution of instruction management between the CPU and programming; what does the CPU need to control? What does the programming need to control?
Although interesting, multiple cores aren't really the next logical step in a better microarchitecture. There are a significant number of other microarchitecture improvements you can make that will have much larger performance implications than multiple cores. To give you an idea, I like to use the history of Intel's microarchitectures as a rough (but surprisingly accurate) guide to what stages which techniques make sense:
8086 - 0.33 MIPS - Minimal working CPU at minimal practical bit width
80286 - 1.28 MIPS - Separate memory bus and memory management circuitry
80386 - 2.15 MIPS - "Goldilocks" bit width, microcode, and usable math coprocessor
80486 - 11.1 MIPS - Pipelining & Caching
Pentium - 100+ MIPS - Superscalar architecture, Branch Prediction, Microcode control over pipeline and superscalar features, separate code and data cache, simple vectorization (MMX), combinatorial multipliers, loading multiple instructions/data simultaneously
Pentium Pro - 541 MIPS - Out-of-order execution, level 2 cache, pre-loaded instruction pool, pre-decoded microcode, speculative execution, superpipelining, register renaming
(Pentium 2 & 3 used same microarchitecture. Pentium 3 was 2,054 MIPS)
Netburst/Pentium 4 - 9,726 MIPS - Simultaneous Multithreading (or "hyperthreading"), "Quad-Pumped Front-Side Bus" (basically meaning ways to read huge amounts of data from RAM at once), Micro-op cache (not dedicated, part of L1 cache), near-optimal branch predictors, maxes out sheer clock speed.
Core microarchitecture - Dual-core is 27,079 MIPS (13,539.5 MIPS/core), Quad-core is 49,161 MIPS (12290.25 MIPS/core) - Multiple cores (finally!), level 3 cache, more efficient decoding, better caching algorithm, more efficient bus usage, dynamic clock speed, hyperthreading is REMOVED for some reason (it is re-added later, not sure why Intel removed it here)
Based on those guidelines, the CPU from my original series was somewhere around the "8086" level, and the CPU from this series should end up being around the "80486" level (although I'm doing a few things from the "Pentium" level, like vectorization). As you can see, there is a small universe of various improvements to be made before you get to multiple cores. If you think about it, it makes sense: Multiple cores at least doubles the circuit size and complexity, yet only improves performance if you have more independent threads of execution than a single core can keep up with. That improvement is actually even less than you'd think, since even ignoring the fact that it's very hard to get the balanced load of independent threads required to take full advantage of multiple cores, a single core can do a surprisingly good job of keeping up with several threads of execution when it has simultaneous multithreading.
What all those "intermediate" optimizations are attacking is instruction level parallelism, meaning different instructions within a program that can be executed simultaneously. That's a much juicier target for performance, because of this: In software, the most performance critical code is in loops, and loops have, quite literally, *infinite* potential for instruction level parallelism. That's how DSP's get such great performance (compared core-for-core, cycle-for-cycle, a typical DSP is almost precisely 2x as fast as the highest-end x86 processor on the market, and at 1/10th the power consumption): Because of the more restricted domain, they can take far better advantage of instruction level parallelism than conventional processors.
Another example of this is in the chart I just showed you: The biggest difference between 80486 and Pentium was the better instruction level parallelism from superscalar architecture, and that resulted in a nearly 10-fold performance increase. In contrast, adding multiple cores lead to a much more modest 40% improvement per-core, and even being unfair and not doing a per-core comparison, it's still only 5x (It's unfair because the numbers assume that all cores will be fully loaded at all times, which as I hinted at earlier, is not even close to true in practice. If you want to see for yourself, pull up your system monitor and see how often all your cores are fully loaded. Unless you're doing a task that's specifically optimized to utilize all cores, the answer is probably "almost never")
Bottom line: Given the choice, by far the best way to address CPU performance is with instruction level parallelism optimization, not multiple cores.
so do real cpus bus using really wide busses between thecache and the ram?
ALU, registers, cache all designed and bused vertically. Ram is using the same buses as the cache but the inputs and outputs, encoding and decoding, are being done horizontally? This doesn’t make a lick of sense to me what am I missing
As far as those preset furnaces go, is there some mod I should be loading so I can find those pre-built?
dwhitaker86 unfortunately no, they are only on ORE, but u can experiment with hoppers or shulker boxes
Hey Benny, I just discovered you're still alive, coming from your programming channel, and I was wondering whether you have any idea when you will be returning to thebennybox?
I didnt have world edit and now i gotts rebuild
im having issues with the ALU input signal strengths
Ryan Dupuis You should check if ur furnaces are the right power or if all pieces of redstone are placed or if your comparators are in subtract mode when needed
What's your texture pack?
The TNTsheep ocd pack
Ainsley's Cousin thx
Hey Benny, like Timo I've found your programming videos extremely useful and would love if you could go back to it, I'm still subscribed to thebennybox:)
Oh man... I built the thing last ep now I got to rebuild it bc I play in mcpe... Seriously....
ayy first commenter great video