Love the video! But.... good music is not necessarily good background music; you've definitely picked foreground music and it's fighting for the attention of the viewer... Keep up the good work!
Love the informative video. You're definitely got the narration part down. It just needs a bit more audio editing and tweaking. The voice over bits seem loud and the moments when the camera goes back to you sound quiet. The music is definitely a good choice, but It's often fighting with you and the rest of the audio that's trying to play. I say keep up the good work. I really enjoyed the informative content in the video. I liked how you also informed everyone right off the bat that ARM and x86 are more just software philosophies and not just hardware ones.
Only got to 1:40 yet and I want to point out that Intel's E-cores are actually (despite the name) NOT primarily efficiency-oriented, that is, power-wise. They are space-efficient first. That is, a cluster of 4 of them occupy the same space as 1 (one) P-core. So 4 threads vs 1+hyperthreading. 4 vs 1 or 4 vs 2 depening on the workload. While slower and with a lower IPC, 4 E-cores do have more compute performance than 1 P core. Edit: Ok, finished the video. This was pretty nice, I'm glad to see somebody actually talking about the details, and pushing against the braindead narative of "aRm Is So mUcH mOrE eFfiCiEnT, hurr durr". Though, from what I understood, the fact that ARM or a RISC ISA has fixed length instructions, while x86 and CISC have variable length does give some advantages to ARM on instruction decoding. And yeah, about the blurriness on what is CISC and RISC. Both x86/x86_64 and ARM decode the ISA instructions into microinstructions. Which should give a good hint on how much impact an ISA has (spoiler: not much). Still, x86 has a lot of legacy instructions that it supports, but from what I understood, phisically, it "bloats" the CPU by like 1% in the extra decoding needed or something like that. At the end of the day, my gut feeling (of a passionate amateur) is that ARM is indeed more efficient than x86, but by something like 5-10%. Assuming the CPU is built with the same manufacturing node and all else equal. That's why I wouldn't worry about x86 disappearing very soon. Also, the CISC side should also have a little ace up their sleeves. While both storage and RAM capacity has increased greatly (frankly, with 64-192 GB of RAM, you can have even Windows 11 installed in a RAM disk. Or Linux + some apps and games) you'd think that the ability of a program for a CISC ISA to be smaller is almost meaningless now. But, the cache sizes haven't increase that dramatically. L1 cache is still 32-96 KBytes. The more you can squeeze the instructions and data and have them all on the same page, the better the caching is. But, of course, for this, the program has to be somewhat optimized. Which I can't say it's the norm nowadays. Lastly, I'd like to add that the music while it's nice and has an ok volume, it is waay too "busy" and distracting to have it as a background music for someboy talking.
You could consider microcode to differentiate between the RISC and CISC. modern x86 and armv8 decode instructions to microcode and the microcode is really what gets executed...
As a really old guy, I worked on System/360 (1964 -- though prior systems had the concepts in places) where you had Central Processors and Channel Processors. Typically, only 1 Central Processor (which had the full instruction set), channels were 5-instruction processors that handled I/O, typically 2 to 16 channels in a processor complex. They mostly communicated through Storage--the CP generating "channel programs" which the kicked off the channel ("SIO = Start IO") which would then run independently of the CP. In fact, the CP could crash but the I/O would merrily continue. (The channel would write results into storage, then interrupt the CP which would then have the data to work on.) You could say that Control Units, which talked to the I/O devices and the channels, had device-specific processors--simple controls for things like disks and displays, but telecom devices would run the lower levels of the protocols and only interrupt the channel when a complete packet of data was available. In the late 60's there were multi-CP complexes and you could see them crash and the telecom would continue. It is scary how much of our business backbone still uses code written in the 1960's--one client I worked with lost the source for a critical business process in the 1980's (they actually had an older version of the source available, but the object code they were running in 2018 was compiled a few years after the source version they had--IBM mainframes today can still run object code generated in the 1960's).
The comments here show how much UA-cam has changed over the years. Great writing and narrative, for having less than 500 subs you are doing great, keep learning and keep going.
Thank you very much for the encouragement, Lord knows I really needed it! Sometimes I feel like I'm so far behind my contemporaries. It's so hard to compete with all this finely curated and excellently produced content in the tech space! I kind of miss the days when you could just sit in front of a camera and talk about what you loved. But don't take that as whinging! I'm gonna do the absolute best I can!
Thank the algorithm for the great content. Few comments on your production, the info was spot on and the script was fantastic. Your vocal presentation is also excellent. The inserted cut scenes and its edits are great, now I want to focus on your on camera segments (not trying to stir drama or be overly nit picky, just what I noticed). 1. When you cut from scene to scene, from point to point, don't do the fade, just make the cuts clean and brisk. There is zero shame in having instant cuts to the next point, the fade and its speed is distracting and/or out of place. 2. You could set the camera a bit farther back, and center yourself using the golden ratio grid (which means your persona is offset from center to the golden ratio) and you could use the extra space on the side for "slides" and graphics that could point out info related to what you are currently saying. Although I understand everything you speak out without issue, some people who are less tech savy but are still interested may need some extra info about the basics, like for example, a graphic showing big.LITTLE as a small graphic showing big and small squares. Small visuals really do help your presentation. 3. I would also tone down the music just ever so slightly, like 2-4db when overplayed on cut scenes. It feels a like the gap between the points where the music is loud, and when it is quiet, is too much. 4. Your slides with bullet points and the animated geometry are quite nice! Just change up the font and condense the information, and maybe use it as an off to the side slide like in point 2. 5. Lighting! Your lighting here was center right (center left from your perspective), and this made the left side of your face quite dark. I would use a warmer light, and use two of them, one higher up on one side, one lower down on the other side, and instead of pointing the light directly at you, point it just a bit off center from your face to give the room a bit more of the flood effect. This could easily be improved with having less dark color palettes in the room. I understand some of this would require gear, tinkering, and a bit more effort, and that is totally up to you, I personally would watch again as is. Thanks for the video.
Good stuff man! The music choice is on point and your script, I felt, was clear and effective in cutting through the ignorant and reductive discourse regarding the influence of ISAs in the modern computing landscape. ISA fanboys must come to understand that things have changed since the 90s...
Much appreciated! I really wanted to reset the discussion on the topic with this vid. Seems general discussion has veered WAY off course. Thanks for watching!
Well said Mike! I can't wait for RISC-V to mature more as a platform, but I feel like we'll be waiting til we're old and grey. It seems like the only people pushing hardware and software for Risc V is the Linux foundation and a few SEA companies avoiding US tech tariffs. We're going to need much larger adoption from the wider industry. I don't want Risc V to stay as a sort of "Tinker's cottage" sort of niche. Thanks for watching and commenting!
@@SiliconFox-s8d I don't see RISC-V growing beyond SOCs. It doesn't have IBM behind it (the only reason PowerPC still exists) and once Sun died (became Snoracle), SPARC (which influences RISC-V) was dead as a mainstream platform. Enterprises like alternatives; x86_64 and arm64 give them sufficient diversity. I don't see them looking at RISC-V. Unless Amazon goes full-steam on RISC-V ec2 it's just not gonna be mainstream. But it will survive in SOCs 'cos it's fast and efficient and cheap :-)
Nice video, cool points. I cannot comment on the validity, but there is one thing I would like to mention: Music. It fits the vibe, but it makes it difficult to listen and understand because it is turbulent and includes voice. If you want your audience to be able to listen and concentrate on what you are saying you should choose a calm music without voice.
Thanks for the feedback! I'm still learning how to edit videos (as you can definitively tell), so I've been doing my best to improve the audio mixing in every subsequent production. I'm still not there yet, but I'll get the hang of it real soon!
Agreed, love the vid, content good and informative and balanced, music was a bit distractiving as was a tad loud during the dialogue. Keep going with the content, good luck with the editing :-)
I don't really see a problem with having background music in the video. What I will say is that the audio mix / balance could be better. As a new creator too, I still occasionally have setup related issues audio. But that will probably resolved as you make more content because you learn something with every video you make.
@@SiliconFox-s8dDon't worry, this video has a lot of views for the age of your channel. You are doing great, your bigger problem right now might just be exposure and a few more videos on hot topics.
things I have in common with Linus Torvalds ... Jobs and Woz "... Hey guys, wanna go trip ballz on Acid and design the Future?" ... "Me Too, but I use AAARRRRCCCCHHHHH!!!! Did you guys spike my Keyboard again?"
I've not seen any of your vids before, but "the algorithm" suggested it. I didn't really learn anything (I'm so old ...) but I think you covered the space very well and you kept interest; I watched to the end. CAL is very interesting because a naive implementation could cause low core starvation; how each platform handles this will influence overall performance. (Side note: I'd go with "critical resource" rather than "critical section", but that's maybe just me; it's how I was taught it far too many years ago!). But (and the main reason I came to post), as with other people... cut back on the background music; in places it was louder than you!
Great video! I have also been tickled funny by people saying that arm is inherently more efficient. As you said in the video, it's a much more nuanced discussion. Also, if you're open to constructive criticism regarding audio; make sure your voice is the same volume throughout the whole video. I noticed that your “talking heads” shots are a little quieter than your “voice-over”/“commentary” shots. Possible solutions; - Use the same microphone setup/positioning for the talking heads & the voice-over - Adjust in Post to make sure the average audio level is the same.
Thanks for watching and the feedback. As I was telling someone earlier, I'm still trying to get a grip on how to balance audio and all that jazz. This video was one of my first attempts at this, so I've been using it as a benchmark to get better. I feel like I'm slooowly getting better lol. I promise I'll get the hang of it soon enough though!
Thanks, will do! If there's one thing I've learned from posting this video . . . *LOWER THE VOLUME!* I actually made a sticky note for my desktop, so I never forget 😂
@@SiliconFox-s8d There are loads of people with ADHD in this field. We can't filter sounds and other distractions. Or rather, we can't control where our attention is focused. Once we notice the music, we can't shift back to listening to the speech and it's game over for us.
Efficiency? Well there's the ridiculously tiny 32 bit SERV core. Its the most efficient 32 bit CPU for the space it takes up on silicon realestate. Its about 250 logic elements... but it does everything serially...
Love the backdrop of jazz with this tech talk! The only think I might suggest is to avoid music with lyrics, as it's muddying your technical dialog a bit. GREAT discussion!
This is highly informative. To add detail to the musix issue, simply lowering the volume and focussing on instrumentals rather than vocal performances should be enaugh. Eill check out the music later maybe, they do sound cool and jazz+tech is a unique brand you can use
I'm going to be a bit sad seeing my new laptop running with an ARM chip, but since RISC computers/laptops is not new, and had been there since 1990s and long before (PowerPC/SPARC), maybe they should consider a marque for ARM laptop/destop chips, like StrongARM, BIGARM, MuscleARM, or HeavyARM
RISC/CISC does not matter. For both arm and intel, every assembly opcode gets broken up into microops internally. That shit does not matter anymore. A micro op is actually what the cpu can do.
@@sweh i wish i was born early enough for that era. Would have been better for me :) massive respect to people back then who learned assembly on that platform. I will never be able to do the same
I think it's critical to point out that RISC isn't just that most instructions complete in one cycle, but ALL instructions MUST execute in a single clock cycle, which is the key reason why x86 is CISC as they have instructions in x86/x86_64 that can not be executed in a single clock cycle. The other major argument in favor of RISC vs. CISC is that you can create any of the additional fancy instruction features in hardware, but it takes 2, 3, or even 4 clocks sometimes, you can create the same operation in a higher level software language and compilers are so efficient now that they will get better efficiency than building in extra instructions and bloating out clock cycles required. Also, with 64 bit computing a standard now, we can expand the list of hardware instructions that can be built into the CPU and still complete in a single clock cycle. One thousand instructions doesn't really seem like a whole lot considering you can contain the entire instruction set into 10-11 bits to address those instructions...which leaves 53-54 bits for specifying registers and storing values. Also, with the extra room in the existing bit (if you had 11 bits and thus 2048 values could be stored), you'd still have addresses that could be usable where you could point to a lookup table or something else that could optimize processes and take something that would have taken two clock cycles (two instructions) and turn it into one clock cycle with lookup tables. Due to legacy with x86 supporting backward compatibility, particularly with 32-bit and 16-bit instructions, some multi-cycle instructions are still going to take multiple clocks and run inefficiently, even with these upgrades in the designs of the x86 CPUs in terms of efficiency and big.little. ALL instructions in RISC are single CPU clock, which means there are several guarantees...you don't get those guarantees in CISC/x86. Very informative video, though, and I thought delivery was pretty good, but my only big critique is that the background music was pretty loud and felt distracting from your content. It was difficult at times to hear your voice over the singer. ARM may have gone a bit overboard in more recent years in adding instructions into the ISA, but as long as they're remaining single clock cycle per instruction as the ceiling, then you remain ahead of x86 and CISC...since you can have instructions take multiple clock cycles. It's really that simple. Also, efficiencies can be gained later in software improvements to compilers, which can make the instruction sequence more efficient to a point that the performance on existing compilers and arm vs. x86, arm is significantly faster than x86 on tasks that essentially don't require an ASIC inside the CPU complex to do extra work (like avx512). Anyway, the deepest parts of the topic certainly can't be covered in just 17 minutes. With the evolutions in the last 20 years of computer science, we've trended toward cross-platform compatibility and building compilers for a language that can compile to more than one or even two instruction sets on usually at least three major OSes (Linux, Windows, and Mac...sorry BSD/Unix...if the language is open, then it's likely you could compile it for BSD/Unix since there's versions for Linux...just more work). Anyway, most modern languages like Rust, Golang, Python, and Ruby all either have an interpreter for a particular OS and ISA or a compiler that will compile to most of the combination of: ARM, x86/x86_64, and maybe MIPS...and then for the OSes: Mac, Linux, and Windows...and if the compiler supports other OSes or the code is open source, one could be built. Point is, most everything can be made more efficient in software over time, so the more minimalistic we are in the hardware now and focus on efficiency of clock cycles, the more power we can save and the faster we can process information in CPUs. This makes RISC generally the better choice in processing. The main reason RISC lost the race back in the 70s and 80s when Intel would give rise to the 8086 processor, there were not nearly as many languages, compilers for various systems, optimizations and iterations on many languages that improved efficiency with newer compilers, and much more that we have today. As a result, there was a lot of efficiency lost when someone would upgrade systems, because the ISA would change and it wouldn't support what they previously wrote...so, now they'd have to rewrite a bunch of software. Backwards compatibility solved that and became the primary reason 8086 took over, because ARM existed back in the 80s and competed against Intel, but there was not quite the ability to keep up when a new ISA released and didn't support certain instructions any more or the way to use the instruction or a set of instructions changed. Modern languages and compilers can have the compiler ready to build for a new language in a matter of weeks or months, depending on the size of the community and can even work with the manufacturers of this new ISA to write the ISA into the compiler, so the compiler could spit out a program that would work on the new ISA and have a fully operational environment in a new architecture at launch.
small point you got wrong. x86 had already won by becoming the basis of dos on the ibm pc. this is best illustrated with the acorn bbc microcomputer, which had a unique design of having a second processor bus. this was basically a standard 6502 based 8 bit home computer, which could also act as a front end system to any other processor hanging of this second processor bus. when it first came out, it did not have any second processors available. a little bit later it had a 6502 processors which gave useful experience with multicore designs for the same instruction set. around the same time, a z80 processor came out, allowing you to also run cp/m which gave a different operating system. a while later, you got a 80186 processor running dos, which gave experience with 16bit. at around the same time you got the 32016 processor, running unix, giving experience with 32bit. later on, they realised they needed to move away from the 6502, and designed the arm chip, which stood for the Acorn Risc Machine. this went on to form the basis for acorns archimedes computers, which were natively 32 bit, and came with an operating system called riscos. you could also get an archimedes variant which could also run unix, which you would dual boot choosing which one to use at boot time, although you could set which was the default. the archimedes was at around the same time that the comodore amiga came out. not bad for a machine designed around the same time as the original apple computer.
how we used computers in those days was actually part of the inspiration for the raspberry pi, with a lot of the features of the bbc microcomputer sneaking into the original design as a cheap fully functioned computer designed for playing with both software and hardware. if you had another processor hanging of the pi via the io bus, you would basically have a modern equivalent with th second processor operating in headless mode, running io through the pi.
10:20 I guess this is what tanked the Atari Jaguar in the mid-90s. They had a multi processor architecture, which fell flat when games were run on the wrong one.
no, the jaguar tanked because it was too expensive, and too late, leading to too small a market to be viable. by this point, businesses had already decided on pcs running dos, the gamers were engaged in the start of the console wars, and the home computing crowd were already consolidating around the commodore amiga. this just did not leave a viable market for the jaguar.
@@grokitall Atari made a great many mistakes at the worse time that contributed to their downfall. Atari was far ahead and innovative with 3D graphics, online gaming, VR, and introducing GPU's to run the display. Since this video is about processors, it is notable that it was a disaster that coders developed games to run on the wrong processor.
I disagree with a lot of this video, but it is one of the more technical videos on the topic and I appreciate it heavily. The main thing I disagree on is that you say it doesn't dictate how the processor is built. This is so wrong. The ISA heavily dictates how a processor is built because a processor must meet the spec of the ISA. An ISA's job isn't to say "this bus must connect to these peripherals and perform these actions", but it requires a certain makeup based on the requirements of the ISA. It boils down to how different sets of requirements lead to different levels of modular core design. An x86 core can either be re-used or re-designed. An arm core is easier to extend because of the modularity constraints it has to conform to. These constraints are rooted in the ISA.
Thanks for the thoughtful comment! I appreciate your input, but I think there's a bit of a misunderstanding here. While the ISA does define what a processor must do in terms of instruction support, it doesn’t *directly* dictate how the processor is physically built. Designers have a lot of flexibility in how they implement an ISA. The modularity of a core, whether ARM or x86, is influenced more by design philosophy and business models (like, ARM's licensing model) than by the ISA itself. For example, take Lunar lake from intel, it has a great deal of modularity and customization, despite the ISA being less modular. The ISA itself is not the determining factor in how modular or extendable a core is, but rather how it's implemented by the designers. ARM cores are often viewed as more "modular" because ARM licenses its designs out. This is rooted in their business approach rather than inherent ISA constraints. Excellent points though!
@@SiliconFox-s8d I think we're just disagreeing on semantics. My knowledge doesn't come from marketing. It comes from working with embedded arm cores every day. I guess you're talking mainly about the cores used as x86 competitors, but they're like a teeny fraction of all arm cores. Nobody anywhere is saying "The ISA states and dictates how the chip is made!" I think you're actually the one focusing on marketing, which is odd because your argument is "Marketing deceiving". And it's true, but you're not actually focusing on the design of the arm cores and how they implement sets of instructions.
Before watching: now with the recent x86 CPU releases, I dont think it does matter as much, unless ARM can actually optimise better with energy efficiency to a significant degree compared to x86. I think in terms of GPU performance though, i think thew new chips still have a shorter battery life compared to gaming on a phone or an android based handheld
As long as it runs the programs I need it to run. And some of them are games. Soo eeeh, mmm. I think that for many programs ARM is just fine. It is when you really need to PUSH for POWER that it might become a problem.
It doesn't matter because the industry is ill. No matter the architecture, we'll adapt. What we won't adapt to is monopoly --- and unless China and Russia get their S together on that front the future is quite bleak.
ARM arquitecture allows the chip to work on "suspended mode" or hibernation. Yeah there it goes. The main diference. Wich was the last time you switched off your phone ? X86 arquitecture, 486, 686 and x64 dot allow conections or resources when the device is swithed off.
What's up with the background music? For a video like this one would like to be able to concentrate properly to be able to digest the information. It's difficult to follow the video with the music blasting.
This was my first video. I didn't know what I was doing, editing wise, so I was sort of just winging things. I honestly never expected this one to blow up like it did. I figured it may get like 10 or so views. I've learned a lot from the comments about the music, so the message is loud and clear on that front. I have a fixed version of this video, without all the blaring jazz, but I just found out that UA-cam doesn't allow you to replace the video, without completely reuploading it. I could have sword that was a feature. Maybe only for partnered channels? At any rate, all my future videos have a much better balance of BGM and voice overs.
@@SiliconFox-s8d Sorry if I came across harsh, didn't mean to. Was just frustrated, because the concent was great, but it was difficult to follow. I later came back and watched it with subtitles 😀 It wasn't optimal, but it helped a lot. You should be happy that people complain about the music! It means they want to hear what you have to say, instead of just moving on.
Good start, note on two things that were misunderstood. First, Instruction Set Architecture isn't a design but rather a language. ISA's define the binary language any processor operates at and become very important when compiling code to binary and then executing that binary code on physical hardware. If anyone wants to get a feel of what the differences in ISA really mean, do a simple program in ASM for each ISA. Second is that RISC is not a CPU type or design spec but a rather a design philosophy. The core tenants are that every instruction should take exactly one clock cycle to execute and there should be no complex memory address's modes. Nothing in the RISC philosophy revolves around arbitrary number of instructions, only that each should take one cycle to execute. This gets important when it comes to instruction scheduling, if I have 32 instructions and I absolutely KNOW that each takes 1 cycle, then I can reliably assume I have 32 cycles worth of work that needs to be scheduled. For Real Time Operating Systems (RTOS's) this is an absolute hard requirement and why most critical system components (power plants, airplanes, missiles, etc) will use a RTOS + RISC (usually MIPS), not for performance but for timing reasons. There is absolutely no such thing as "CISC", it was a word invented by people who thought RISC was a design spec. There is only RISC and not-RISC, or rather every instruction takes 1 cycle or they do not take 1 cycle. BTW there hasn't been an x86 built in decades now. Both Intel and AMD build RISC processors with a front end instruction decoder / scheduler that speaks x86. x86 instructions go into that decoder and comes out as RISC instructions called micro-operations where they get scheduled onto hardware resources.
Locks are different. They are needed when running parallel threads. A process needs a lock, if it wants to keep other processes from messing up the data it needs for its tasks. Or something along those lines.
x86 is old and antiquated. Time to give it its gold watch and move on. Apple has proven the RISC architecture to be far more efficient. BTW, it's not the number of instructions that matters. It's the complexity of them. It's keeping the instructions as uniform in clock cycles as possible. You can think of it as what Henry Ford did to make his assembly lines work.
ARM is the better architecture because it removes unnecessary complexity. CISC was designed to be convenient for writing assembly code and writing compilers, but RISC is the better design. Even Intel has realized this and all their cores are actually RISC cores for ages, but x86 is a CISC instruction set. So there is a translation unit that has to translate complex instructions (it's in the name, the "C" in CISC stands for complex) into much simpler instructions that the CPU can execute. And that comes with a lot of problems. You need extra transistors, die space, and power supply just for that translation unit, the translation unit adds delay, the translation unit has caused many security bugs in the past, the translation unit has to be excellent, otherwise the best code in the world will run slowly (since its output can turn super code into crappy code otherwise), and compilers cannot really optimize the code because the code they produce at output is not the code that will end up being executed on the CPU (and they cannot know what code a translation unit will make out of their code). ARM on the other hand is already fed RISC instructions and may have a translation unit to break RISC instructions into micro-instructions, but that's optional and up to the CPU designer. Technically, you can build an ARM CPU that executes instructions as they are. You can see the difference by the fact that when Intel has a security flaw in the instruction set itself, they release a patch for the CPU, so there is code running on the CPU that changes how the instructions are executed. When they found a problem with Apple's M1 (which is pretty uncritical, by the way, since you cannot exploit it remotely and even a local exploit is hard to do), Apple had no way to fix it because there is no firmware involved, everything about the instructions is hardwired, which is why the M1 killed all Intel CPUs of its time in pretty much all benchmarks. And that's IMHO how CPUs should work. CPUs are not supposed to be microcomputers that emulate a CPU or an instruction set, they are supposed to be number crunching computing beasts that are dumb as sh... but fast and efficient and all the intelligence should be provided by the software, compilers and interpreters, because software is always easily replaceable and compilers can always produce better code for old CPUs in the future.
It's interesting that the additional abstraction layer imposed by the necessary translation step (in the case of x86) can be leveraged for additional security, though.
@@firecat6666 It can, but bear in mind that often the security problem would not even exist without this unit. So once it is known, the layer is helpful, but what about all the problems that only underground hackers and intelligence agencies know about? In general, any unnecessary complexity is considered a bad thing when it comes to security. The simpler a system is, the easier it is to design correctly and without security flaws. And it's still easier to change software than to patch firmware. Instead of changing the way the CPU translates instructions on CISC, you can change the way compilers produce code for RISC, and that often has the same effect. Patching a compiler is easier and less risky than patching a CPU. The only downside is that after patching the compiler, the code has to be rebuilt once, whereas a patched CPU would now run the old code correctly. Also, I didn't want to make it sound like ARM doesn't have firmware. ARM CPUs do have firmware, because even though RISC instructions can be hardwired, it doesn't pay off in all cases. Some instructions are so infrequent and not performance critical that it makes no sense to hardwire them, but instead use a bunch of other instructions to emulate them. The difference is that in modern CISC CPUs, all instructions must be translated, whereas in modern RISC CPUs, the CPU designer can choose when to hardcode an instruction, when to translate an instruction, and when to use a hybrid model of both. And even that is a level of flexibility that IMHO speaks for RISC.
@@xcoder1122 The thing about cyber security is that nowadays we're WAY past the point where you can design a system simple enough that it's easy to design it bug-free. I agree with you that unnecessary complexity is a sure-fire way to introduce more bugs/vulnerabilities but no system is ever 100% safe (well, I guess if it's broken and doesn't work anymore then it's safe... but then it's also broken and doesn't work anymore). Many of these abstraction layers are there simply to make it harder for malicious actors to run arbitrary code on the hardware. The most obvious example I can think of is separating programs running on the kernel from userland programs. Is this abstraction layer really necessary at the end of the day? No, not really. Does it make your system more secure? Yes, it does. While this isn't the reason why the translation hardware exists in x86, I thought it was interesting that it could be leveraged for additional security (your example of the unfixable M1 CPU vulnerability was a good example of how the x86 translation hardware makes x86 CPUs *potentially* more secure).
RISC vs CISC doesnt matter anymore, all modern high performance chips even the "RISC" chips simulate some or all of the ISA in microcode because GBOoO is a massive Performance increase and more stable than implemcenting Out of Order execution in the operating system. Also M1 uses microcode and a firmware, it has 8 instruction decoders with thumb-2 support and support for SVE2, the "controversial at the time" CISC-like and variable-length instructions that speed up tasks like media encode/decode on ARM by over 800% since those hit the load-store bottleneck extremely quickly and benefitted greatly from microcode. Even on X86, 14-18 instructions are hardwired depending on the CPU, just x86 makes heavier use of traditional microcode for now.
@@ghost-jesus You named the difference yourself. " even the "RISC" chips simulate some" - but not all. If you look at Apple's ARM CPU design, you'll notice that in fact most arithmetic instructions are in fact pure hardwired silicone. x86 on the other hand has not a single instruction of that kind, it cannot have such instructions as the core doesn't know anything about x86 ISA, it speaks a different language for ages and x86 instruction are no longer suitable to even be hardwired. Even if you would want to do that, there is no chance you could still do it. And that's also what I wrote. I did write that some RISC instructions are not hardwired, didn't I? I did say that the M1 has a firmware, didn't I? Why do you think you are contradicting me by just repeating what I already said before? But I also pointed out that not all CPU instructions are controlled by firmware, otherwise Apple could fix this one security design flaw that is known for M1 and they cannot as no firmware is involved in the instruction leading to this issue. And 8 instruction decoders with thumb-2 support has nothing to do with the topic at all. Instruction decoders do no translate instructions, they decode (hence the name) instructions, which means thy forward the instructions to the correct processing unit and make sure this unit is in the right state to perform the operation. All of that can be done purely in hardware if desired, no firmware or translation necessary. Also thumb-2 can be implemented 100% in hardware if you want to, as all thumb-instructions can be mapped to non-thumb ARM instructions purely by only by interconnecting conductors. Again, it's all about what can be done vs what must be done. x86 must be translated and handled by firmware, nothing else is possible anymore. ARM doesn't force you to ever do that. It's totally up to the CPU designer if they want to do that, where when and for which instruction that want to. And this means a lot of flexibility and flexibility is good, as it leads to better designs compared to compared to being constrained by a framework from the outset.
This comment hurts more than any insult one could give. My poor heart 😭 . . . I know I poorly edited and mixed this video, but Jazz is AMAZING! Please go listen to the Quasimode "Land of Freedom" Album. It's quintessential for anyone even slightly curious about the genre. Basically "required reading" my friend. Jazz will change your life! 🎵🎺🎷🎹🎶
@@SiliconFox-s8d nah fam, I hate jazz. I listen to Chill Out electronic. I grew up with a jazz enthusiast father. Can't stand jazz. Loved your video though.
Love the video! But.... good music is not necessarily good background music; you've definitely picked foreground music and it's fighting for the attention of the viewer... Keep up the good work!
Love the informative video. You're definitely got the narration part down. It just needs a bit more audio editing and tweaking. The voice over bits seem loud and the moments when the camera goes back to you sound quiet. The music is definitely a good choice, but It's often fighting with you and the rest of the audio that's trying to play. I say keep up the good work. I really enjoyed the informative content in the video. I liked how you also informed everyone right off the bat that ARM and x86 are more just software philosophies and not just hardware ones.
Only got to 1:40 yet and I want to point out that Intel's E-cores are actually (despite the name) NOT primarily efficiency-oriented, that is, power-wise. They are space-efficient first.
That is, a cluster of 4 of them occupy the same space as 1 (one) P-core. So 4 threads vs 1+hyperthreading. 4 vs 1 or 4 vs 2 depening on the workload. While slower and with a lower IPC, 4 E-cores do have more compute performance than 1 P core.
Edit: Ok, finished the video. This was pretty nice, I'm glad to see somebody actually talking about the details, and pushing against the braindead narative of "aRm Is So mUcH mOrE eFfiCiEnT, hurr durr".
Though, from what I understood, the fact that ARM or a RISC ISA has fixed length instructions, while x86 and CISC have variable length does give some advantages to ARM on instruction decoding.
And yeah, about the blurriness on what is CISC and RISC. Both x86/x86_64 and ARM decode the ISA instructions into microinstructions. Which should give a good hint on how much impact an ISA has (spoiler: not much).
Still, x86 has a lot of legacy instructions that it supports, but from what I understood, phisically, it "bloats" the CPU by like 1% in the extra decoding needed or something like that.
At the end of the day, my gut feeling (of a passionate amateur) is that ARM is indeed more efficient than x86, but by something like 5-10%. Assuming the CPU is built with the same manufacturing node and all else equal. That's why I wouldn't worry about x86 disappearing very soon. Also, the CISC side should also have a little ace up their sleeves. While both storage and RAM capacity has increased greatly (frankly, with 64-192 GB of RAM, you can have even Windows 11 installed in a RAM disk. Or Linux + some apps and games) you'd think that the ability of a program for a CISC ISA to be smaller is almost meaningless now. But, the cache sizes haven't increase that dramatically. L1 cache is still 32-96 KBytes. The more you can squeeze the instructions and data and have them all on the same page, the better the caching is. But, of course, for this, the program has to be somewhat optimized. Which I can't say it's the norm nowadays.
Lastly, I'd like to add that the music while it's nice and has an ok volume, it is waay too "busy" and distracting to have it as a background music for someboy talking.
RISC-V has variable length instructions, son.
You could consider microcode to differentiate between the RISC and CISC. modern x86 and armv8 decode instructions to microcode and the microcode is really what gets executed...
@@kayakMike1000 Oh, didn't know that RISC-V has variable length instructions. Thanks!
that was such an awesome video. defiantly subbed
As a really old guy, I worked on System/360 (1964 -- though prior systems had the concepts in places) where you had Central Processors and Channel Processors. Typically, only 1 Central Processor (which had the full instruction set), channels were 5-instruction processors that handled I/O, typically 2 to 16 channels in a processor complex. They mostly communicated through Storage--the CP generating "channel programs" which the kicked off the channel ("SIO = Start IO") which would then run independently of the CP. In fact, the CP could crash but the I/O would merrily continue. (The channel would write results into storage, then interrupt the CP which would then have the data to work on.) You could say that Control Units, which talked to the I/O devices and the channels, had device-specific processors--simple controls for things like disks and displays, but telecom devices would run the lower levels of the protocols and only interrupt the channel when a complete packet of data was available. In the late 60's there were multi-CP complexes and you could see them crash and the telecom would continue. It is scary how much of our business backbone still uses code written in the 1960's--one client I worked with lost the source for a critical business process in the 1980's (they actually had an older version of the source available, but the object code they were running in 2018 was compiled a few years after the source version they had--IBM mainframes today can still run object code generated in the 1960's).
The comments here show how much UA-cam has changed over the years. Great writing and narrative, for having less than 500 subs you are doing great, keep learning and keep going.
Thank you very much for the encouragement, Lord knows I really needed it! Sometimes I feel like I'm so far behind my contemporaries. It's so hard to compete with all this finely curated and excellently produced content in the tech space!
I kind of miss the days when you could just sit in front of a camera and talk about what you loved. But don't take that as whinging! I'm gonna do the absolute best I can!
Yeah, I thought the music was distracting too, but only because it's so nice! You and the good music were competing for my brain's attention.
Thank the algorithm for the great content.
Few comments on your production, the info was spot on and the script was fantastic. Your vocal presentation is also excellent.
The inserted cut scenes and its edits are great, now I want to focus on your on camera segments (not trying to stir drama or be overly nit picky, just what I noticed).
1. When you cut from scene to scene, from point to point, don't do the fade, just make the cuts clean and brisk. There is zero shame in having instant cuts to the next point, the fade and its speed is distracting and/or out of place.
2. You could set the camera a bit farther back, and center yourself using the golden ratio grid (which means your persona is offset from center to the golden ratio) and you could use the extra space on the side for "slides" and graphics that could point out info related to what you are currently saying. Although I understand everything you speak out without issue, some people who are less tech savy but are still interested may need some extra info about the basics, like for example, a graphic showing big.LITTLE as a small graphic showing big and small squares. Small visuals really do help your presentation.
3. I would also tone down the music just ever so slightly, like 2-4db when overplayed on cut scenes. It feels a like the gap between the points where the music is loud, and when it is quiet, is too much.
4. Your slides with bullet points and the animated geometry are quite nice! Just change up the font and condense the information, and maybe use it as an off to the side slide like in point 2.
5. Lighting! Your lighting here was center right (center left from your perspective), and this made the left side of your face quite dark. I would use a warmer light, and use two of them, one higher up on one side, one lower down on the other side, and instead of pointing the light directly at you, point it just a bit off center from your face to give the room a bit more of the flood effect. This could easily be improved with having less dark color palettes in the room.
I understand some of this would require gear, tinkering, and a bit more effort, and that is totally up to you, I personally would watch again as is.
Thanks for the video.
music background is a little loud, and distracting.
Great presentation and great music. Unfortunately, my ear was drawn to the music much too easily. I would rather keep the two separate.
This is way to well produced for just 250 subs
I barely even realized you had such a small amount of subscribers. Dropped a sub!
Dude, I'd never think to mix tech with jazz. This is my new favorite channel :D
🎵🎷🎺🎹🎶
Nice vid
Appreciate the support!
Was an interesting video but the music was too loud...
This is well put together man. Glad it came across my feed. Keep 'em up!
Good stuff man! The music choice is on point and your script, I felt, was clear and effective in cutting through the ignorant and reductive discourse regarding the influence of ISAs in the modern computing landscape. ISA fanboys must come to understand that things have changed since the 90s...
Much appreciated! I really wanted to reset the discussion on the topic with this vid. Seems general discussion has veered WAY off course. Thanks for watching!
Not really. Now arm v. RISC-V... Thats an interesting story
Well said Mike! I can't wait for RISC-V to mature more as a platform, but I feel like we'll be waiting til we're old and grey. It seems like the only people pushing hardware and software for Risc V is the Linux foundation and a few SEA companies avoiding US tech tariffs. We're going to need much larger adoption from the wider industry. I don't want Risc V to stay as a sort of "Tinker's cottage" sort of niche.
Thanks for watching and commenting!
@@SiliconFox-s8d I don't see RISC-V growing beyond SOCs. It doesn't have IBM behind it (the only reason PowerPC still exists) and once Sun died (became Snoracle), SPARC (which influences RISC-V) was dead as a mainstream platform.
Enterprises like alternatives; x86_64 and arm64 give them sufficient diversity. I don't see them looking at RISC-V. Unless Amazon goes full-steam on RISC-V ec2 it's just not gonna be mainstream.
But it will survive in SOCs 'cos it's fast and efficient and cheap :-)
Nice video, cool points. I cannot comment on the validity, but there is one thing I would like to mention: Music. It fits the vibe, but it makes it difficult to listen and understand because it is turbulent and includes voice. If you want your audience to be able to listen and concentrate on what you are saying you should choose a calm music without voice.
Oh i love this video, interesting topic and the pacing of your speech isn't suffocating unlike other videos I've seen. Please keep it up
The make-up of the video is terrible. Am I supposed to listen to the elevator music or the talking?
Thanks for the feedback! I'm still learning how to edit videos (as you can definitively tell), so I've been doing my best to improve the audio mixing in every subsequent production.
I'm still not there yet, but I'll get the hang of it real soon!
Agreed, love the vid, content good and informative and balanced, music was a bit distractiving as was a tad loud during the dialogue.
Keep going with the content, good luck with the editing :-)
I don't really see a problem with having background music in the video.
What I will say is that the audio mix / balance could be better. As a new creator too, I still occasionally have setup related issues audio. But that will probably resolved as you make more content because you learn something with every video you make.
@@SiliconFox-s8dDon't worry, this video has a lot of views for the age of your channel. You are doing great, your bigger problem right now might just be exposure and a few more videos on hot topics.
Ditto, background music overwhelming content. Also, look up pronunciation of heterogeneous.
I liked how you narrated this whole thing. Also liked how you did not take sides as the crowd does usually in this matter.
things I have in common with Linus Torvalds
... Jobs and Woz "... Hey guys, wanna go trip ballz on Acid and design the Future?"
... "Me Too, but I use AAARRRRCCCCHHHHH!!!! Did you guys spike my Keyboard again?"
Solidly subbed! All your points are well chosen and explained!
I've not seen any of your vids before, but "the algorithm" suggested it. I didn't really learn anything (I'm so old ...) but I think you covered the space very well and you kept interest; I watched to the end.
CAL is very interesting because a naive implementation could cause low core starvation; how each platform handles this will influence overall performance. (Side note: I'd go with "critical resource" rather than "critical section", but that's maybe just me; it's how I was taught it far too many years ago!).
But (and the main reason I came to post), as with other people... cut back on the background music; in places it was louder than you!
Great video, thank you. Absolutely love the music! Listened to them a lot when the album was released.
Amazing video! But yeah, music should be a bit lowered 😅
Nice video, maybe music a little low next time.
Great video! I have also been tickled funny by people saying that arm is inherently more efficient. As you said in the video, it's a much more nuanced discussion.
Also, if you're open to constructive criticism regarding audio; make sure your voice is the same volume throughout the whole video. I noticed that your “talking heads” shots are a little quieter than your “voice-over”/“commentary” shots.
Possible solutions;
- Use the same microphone setup/positioning for the talking heads & the voice-over
- Adjust in Post to make sure the average audio level is the same.
Thanks for watching and the feedback. As I was telling someone earlier, I'm still trying to get a grip on how to balance audio and all that jazz. This video was one of my first attempts at this, so I've been using it as a benchmark to get better. I feel like I'm slooowly getting better lol. I promise I'll get the hang of it soon enough though!
Sound quality bad in this vedio
lower the music volume in the background; keep up the good work, you're doing great! :D
Thanks, will do! If there's one thing I've learned from posting this video . . . *LOWER THE VOLUME!* I actually made a sticky note for my desktop, so I never forget 😂
@@SiliconFox-s8d There are loads of people with ADHD in this field. We can't filter sounds and other distractions. Or rather, we can't control where our attention is focused. Once we notice the music, we can't shift back to listening to the speech and it's game over for us.
Efficiency? Well there's the ridiculously tiny 32 bit SERV core. Its the most efficient 32 bit CPU for the space it takes up on silicon realestate. Its about 250 logic elements... but it does everything serially...
Awesome video
Love the backdrop of jazz with this tech talk! The only think I might suggest is to avoid music with lyrics, as it's muddying your technical dialog a bit. GREAT discussion!
Take my comment to pull you up. Good video, good job.
This is highly informative.
To add detail to the musix issue, simply lowering the volume and focussing on instrumentals rather than vocal performances should be enaugh. Eill check out the music later maybe, they do sound cool and jazz+tech is a unique brand you can use
I like the vibe of this video. You're a good storyteller, and I feel like I learned something without being lectured to.
It's heterogen-e-ous.
Nope. It's the antonym of Homogenous. As in homogenous milk. How do most North Americans pronounce that?
Great video!
And great album!
Really nice job on this - a clear and balanced take.
This music is a WILD choice for background filler, might have been ok if it was instrumental. Even then, it's pretty busy.
Thank you so much. It's a very informative overview of the technology evolution.
I'm going to be a bit sad seeing my new laptop running with an ARM chip, but since RISC computers/laptops is not new, and had been there since 1990s and long before (PowerPC/SPARC), maybe they should consider a marque for ARM laptop/destop chips, like StrongARM, BIGARM, MuscleARM, or HeavyARM
RISC/CISC does not matter. For both arm and intel, every assembly opcode gets broken up into microops internally. That shit does not matter anymore. A micro op is actually what the cpu can do.
@@runninggames771 Bring back the 6502; no real microcode layer to talk about; each instruction was hardcoded into silicon! Now that's RISC :-)
@@sweh i wish i was born early enough for that era. Would have been better for me :) massive respect to people back then who learned assembly on that platform. I will never be able to do the same
I think it's critical to point out that RISC isn't just that most instructions complete in one cycle, but ALL instructions MUST execute in a single clock cycle, which is the key reason why x86 is CISC as they have instructions in x86/x86_64 that can not be executed in a single clock cycle.
The other major argument in favor of RISC vs. CISC is that you can create any of the additional fancy instruction features in hardware, but it takes 2, 3, or even 4 clocks sometimes, you can create the same operation in a higher level software language and compilers are so efficient now that they will get better efficiency than building in extra instructions and bloating out clock cycles required.
Also, with 64 bit computing a standard now, we can expand the list of hardware instructions that can be built into the CPU and still complete in a single clock cycle. One thousand instructions doesn't really seem like a whole lot considering you can contain the entire instruction set into 10-11 bits to address those instructions...which leaves 53-54 bits for specifying registers and storing values. Also, with the extra room in the existing bit (if you had 11 bits and thus 2048 values could be stored), you'd still have addresses that could be usable where you could point to a lookup table or something else that could optimize processes and take something that would have taken two clock cycles (two instructions) and turn it into one clock cycle with lookup tables.
Due to legacy with x86 supporting backward compatibility, particularly with 32-bit and 16-bit instructions, some multi-cycle instructions are still going to take multiple clocks and run inefficiently, even with these upgrades in the designs of the x86 CPUs in terms of efficiency and big.little. ALL instructions in RISC are single CPU clock, which means there are several guarantees...you don't get those guarantees in CISC/x86.
Very informative video, though, and I thought delivery was pretty good, but my only big critique is that the background music was pretty loud and felt distracting from your content. It was difficult at times to hear your voice over the singer.
ARM may have gone a bit overboard in more recent years in adding instructions into the ISA, but as long as they're remaining single clock cycle per instruction as the ceiling, then you remain ahead of x86 and CISC...since you can have instructions take multiple clock cycles. It's really that simple. Also, efficiencies can be gained later in software improvements to compilers, which can make the instruction sequence more efficient to a point that the performance on existing compilers and arm vs. x86, arm is significantly faster than x86 on tasks that essentially don't require an ASIC inside the CPU complex to do extra work (like avx512).
Anyway, the deepest parts of the topic certainly can't be covered in just 17 minutes. With the evolutions in the last 20 years of computer science, we've trended toward cross-platform compatibility and building compilers for a language that can compile to more than one or even two instruction sets on usually at least three major OSes (Linux, Windows, and Mac...sorry BSD/Unix...if the language is open, then it's likely you could compile it for BSD/Unix since there's versions for Linux...just more work). Anyway, most modern languages like Rust, Golang, Python, and Ruby all either have an interpreter for a particular OS and ISA or a compiler that will compile to most of the combination of: ARM, x86/x86_64, and maybe MIPS...and then for the OSes: Mac, Linux, and Windows...and if the compiler supports other OSes or the code is open source, one could be built. Point is, most everything can be made more efficient in software over time, so the more minimalistic we are in the hardware now and focus on efficiency of clock cycles, the more power we can save and the faster we can process information in CPUs. This makes RISC generally the better choice in processing.
The main reason RISC lost the race back in the 70s and 80s when Intel would give rise to the 8086 processor, there were not nearly as many languages, compilers for various systems, optimizations and iterations on many languages that improved efficiency with newer compilers, and much more that we have today. As a result, there was a lot of efficiency lost when someone would upgrade systems, because the ISA would change and it wouldn't support what they previously wrote...so, now they'd have to rewrite a bunch of software. Backwards compatibility solved that and became the primary reason 8086 took over, because ARM existed back in the 80s and competed against Intel, but there was not quite the ability to keep up when a new ISA released and didn't support certain instructions any more or the way to use the instruction or a set of instructions changed. Modern languages and compilers can have the compiler ready to build for a new language in a matter of weeks or months, depending on the size of the community and can even work with the manufacturers of this new ISA to write the ISA into the compiler, so the compiler could spit out a program that would work on the new ISA and have a fully operational environment in a new architecture at launch.
small point you got wrong.
x86 had already won by becoming the basis of dos on the ibm pc.
this is best illustrated with the acorn bbc microcomputer, which had a unique design of having a second processor bus.
this was basically a standard 6502 based 8 bit home computer, which could also act as a front end system to any other processor hanging of this second processor bus.
when it first came out, it did not have any second processors available.
a little bit later it had a 6502 processors which gave useful experience with multicore designs for the same instruction set.
around the same time, a z80 processor came out, allowing you to also run cp/m which gave a different operating system.
a while later, you got a 80186 processor running dos, which gave experience with 16bit.
at around the same time you got the 32016 processor, running unix, giving experience with 32bit.
later on, they realised they needed to move away from the 6502, and designed the arm chip, which stood for the Acorn Risc Machine.
this went on to form the basis for acorns archimedes computers, which were natively 32 bit, and came with an operating system called riscos.
you could also get an archimedes variant which could also run unix, which you would dual boot choosing which one to use at boot time, although you could set which was the default.
the archimedes was at around the same time that the comodore amiga came out.
not bad for a machine designed around the same time as the original apple computer.
how we used computers in those days was actually part of the inspiration for the raspberry pi, with a lot of the features of the bbc microcomputer sneaking into the original design as a cheap fully functioned computer designed for playing with both software and hardware.
if you had another processor hanging of the pi via the io bus, you would basically have a modern equivalent with th second processor operating in headless mode, running io through the pi.
10:20 I guess this is what tanked the Atari Jaguar in the mid-90s. They had a multi processor architecture, which fell flat when games were run on the wrong one.
no, the jaguar tanked because it was too expensive, and too late, leading to too small a market to be viable.
by this point, businesses had already decided on pcs running dos, the gamers were engaged in the start of the console wars, and the home computing crowd were already consolidating around the commodore amiga. this just did not leave a viable market for the jaguar.
@@grokitall Atari made a great many mistakes at the worse time that contributed to their downfall. Atari was far ahead and innovative with 3D graphics, online gaming, VR, and introducing GPU's to run the display. Since this video is about processors, it is notable that it was a disaster that coders developed games to run on the wrong processor.
I disagree with a lot of this video, but it is one of the more technical videos on the topic and I appreciate it heavily. The main thing I disagree on is that you say it doesn't dictate how the processor is built. This is so wrong. The ISA heavily dictates how a processor is built because a processor must meet the spec of the ISA. An ISA's job isn't to say "this bus must connect to these peripherals and perform these actions", but it requires a certain makeup based on the requirements of the ISA. It boils down to how different sets of requirements lead to different levels of modular core design. An x86 core can either be re-used or re-designed. An arm core is easier to extend because of the modularity constraints it has to conform to. These constraints are rooted in the ISA.
Thanks for the thoughtful comment! I appreciate your input, but I think there's a bit of a misunderstanding here.
While the ISA does define what a processor must do in terms of instruction support, it doesn’t *directly* dictate how the processor is physically built. Designers have a lot of flexibility in how they implement an ISA. The modularity of a core, whether ARM or x86, is influenced more by design philosophy and business models (like, ARM's licensing model) than by the ISA itself.
For example, take Lunar lake from intel, it has a great deal of modularity and customization, despite the ISA being less modular. The ISA itself is not the determining factor in how modular or extendable a core is, but rather how it's implemented by the designers.
ARM cores are often viewed as more "modular" because ARM licenses its designs out. This is rooted in their business approach rather than inherent ISA constraints. Excellent points though!
@@SiliconFox-s8d I think we're just disagreeing on semantics. My knowledge doesn't come from marketing. It comes from working with embedded arm cores every day. I guess you're talking mainly about the cores used as x86 competitors, but they're like a teeny fraction of all arm cores. Nobody anywhere is saying "The ISA states and dictates how the chip is made!" I think you're actually the one focusing on marketing, which is odd because your argument is "Marketing deceiving". And it's true, but you're not actually focusing on the design of the arm cores and how they implement sets of instructions.
Before watching: now with the recent x86 CPU releases, I dont think it does matter as much, unless ARM can actually optimise better with energy efficiency to a significant degree compared to x86. I think in terms of GPU performance though, i think thew new chips still have a shorter battery life compared to gaming on a phone or an android based handheld
This is a really great video!
As long as it runs the programs I need it to run.
And some of them are games. Soo eeeh, mmm.
I think that for many programs ARM is just fine. It is when you really need to PUSH for POWER that it might become a problem.
I couldn't watch the video at all because of the background music that was making my attention constantly move away from the visuals.
they are not energy efficient cores. efficiency cores are LESS energy efficient. they are SPACE efficient, you can fit more in the same space.
It doesn't matter because the industry is ill. No matter the architecture, we'll adapt. What we won't adapt to is monopoly --- and unless China and Russia get their S together on that front the future is quite bleak.
Portability and cross-compatibility!
ARM arquitecture allows the chip to work on "suspended mode" or hibernation.
Yeah there it goes. The main diference.
Wich was the last time you switched off your phone ?
X86 arquitecture, 486, 686 and x64 dot allow conections or resources when the device is swithed off.
1 key suggestion, please keep the music down more
What's up with the background music? For a video like this one would like to be able to concentrate properly to be able to digest the information. It's difficult to follow the video with the music blasting.
This was my first video. I didn't know what I was doing, editing wise, so I was sort of just winging things. I honestly never expected this one to blow up like it did. I figured it may get like 10 or so views.
I've learned a lot from the comments about the music, so the message is loud and clear on that front. I have a fixed version of this video, without all the blaring jazz, but I just found out that UA-cam doesn't allow you to replace the video, without completely reuploading it. I could have sword that was a feature. Maybe only for partnered channels?
At any rate, all my future videos have a much better balance of BGM and voice overs.
@@SiliconFox-s8d Sorry if I came across harsh, didn't mean to. Was just frustrated, because the concent was great, but it was difficult to follow. I later came back and watched it with subtitles 😀 It wasn't optimal, but it helped a lot. You should be happy that people complain about the music! It means they want to hear what you have to say, instead of just moving on.
it matters because if arm wins, more old programs will fail to run
Great Video!!!!!
Dude, don't use BGM with vocals while there's someone talking. It's just awful.
Trust me. The message is now loud and clear 😅That's one mistake I'm not going to do again!
Bring back DECAlpha.
Good start, note on two things that were misunderstood. First, Instruction Set Architecture isn't a design but rather a language. ISA's define the binary language any processor operates at and become very important when compiling code to binary and then executing that binary code on physical hardware. If anyone wants to get a feel of what the differences in ISA really mean, do a simple program in ASM for each ISA. Second is that RISC is not a CPU type or design spec but a rather a design philosophy. The core tenants are that every instruction should take exactly one clock cycle to execute and there should be no complex memory address's modes. Nothing in the RISC philosophy revolves around arbitrary number of instructions, only that each should take one cycle to execute. This gets important when it comes to instruction scheduling, if I have 32 instructions and I absolutely KNOW that each takes 1 cycle, then I can reliably assume I have 32 cycles worth of work that needs to be scheduled. For Real Time Operating Systems (RTOS's) this is an absolute hard requirement and why most critical system components (power plants, airplanes, missiles, etc) will use a RTOS + RISC (usually MIPS), not for performance but for timing reasons. There is absolutely no such thing as "CISC", it was a word invented by people who thought RISC was a design spec. There is only RISC and not-RISC, or rather every instruction takes 1 cycle or they do not take 1 cycle.
BTW there hasn't been an x86 built in decades now. Both Intel and AMD build RISC processors with a front end instruction decoder / scheduler that speaks x86. x86 instructions go into that decoder and comes out as RISC instructions called micro-operations where they get scheduled onto hardware resources.
It matters if you're a gamer.
nary a mention of VLIW?!
Just because you like jazz doesn't mean it's a good idea to use it as 'background' music over spoken word.
🫡🫡 Understood!
Sorry, I really want to watch this, but the music makes it impossible to follow what you're saying.
talking about locks? doesn't it mean scheduling algorithm i studied it in my os class.... like round robin, fifo etc etc
Locks are different. They are needed when running parallel threads. A process needs a lock, if it wants to keep other processes from messing up the data it needs for its tasks. Or something along those lines.
x86 is old and antiquated. Time to give it its gold watch and move on. Apple has proven the RISC architecture to be far more efficient. BTW, it's not the number of instructions that matters. It's the complexity of them. It's keeping the instructions as uniform in clock cycles as possible. You can think of it as what Henry Ford did to make his assembly lines work.
ARM is the better architecture because it removes unnecessary complexity. CISC was designed to be convenient for writing assembly code and writing compilers, but RISC is the better design. Even Intel has realized this and all their cores are actually RISC cores for ages, but x86 is a CISC instruction set. So there is a translation unit that has to translate complex instructions (it's in the name, the "C" in CISC stands for complex) into much simpler instructions that the CPU can execute.
And that comes with a lot of problems. You need extra transistors, die space, and power supply just for that translation unit, the translation unit adds delay, the translation unit has caused many security bugs in the past, the translation unit has to be excellent, otherwise the best code in the world will run slowly (since its output can turn super code into crappy code otherwise), and compilers cannot really optimize the code because the code they produce at output is not the code that will end up being executed on the CPU (and they cannot know what code a translation unit will make out of their code).
ARM on the other hand is already fed RISC instructions and may have a translation unit to break RISC instructions into micro-instructions, but that's optional and up to the CPU designer. Technically, you can build an ARM CPU that executes instructions as they are. You can see the difference by the fact that when Intel has a security flaw in the instruction set itself, they release a patch for the CPU, so there is code running on the CPU that changes how the instructions are executed. When they found a problem with Apple's M1 (which is pretty uncritical, by the way, since you cannot exploit it remotely and even a local exploit is hard to do), Apple had no way to fix it because there is no firmware involved, everything about the instructions is hardwired, which is why the M1 killed all Intel CPUs of its time in pretty much all benchmarks.
And that's IMHO how CPUs should work. CPUs are not supposed to be microcomputers that emulate a CPU or an instruction set, they are supposed to be number crunching computing beasts that are dumb as sh... but fast and efficient and all the intelligence should be provided by the software, compilers and interpreters, because software is always easily replaceable and compilers can always produce better code for old CPUs in the future.
It's interesting that the additional abstraction layer imposed by the necessary translation step (in the case of x86) can be leveraged for additional security, though.
@@firecat6666 It can, but bear in mind that often the security problem would not even exist without this unit. So once it is known, the layer is helpful, but what about all the problems that only underground hackers and intelligence agencies know about? In general, any unnecessary complexity is considered a bad thing when it comes to security. The simpler a system is, the easier it is to design correctly and without security flaws.
And it's still easier to change software than to patch firmware. Instead of changing the way the CPU translates instructions on CISC, you can change the way compilers produce code for RISC, and that often has the same effect. Patching a compiler is easier and less risky than patching a CPU. The only downside is that after patching the compiler, the code has to be rebuilt once, whereas a patched CPU would now run the old code correctly.
Also, I didn't want to make it sound like ARM doesn't have firmware. ARM CPUs do have firmware, because even though RISC instructions can be hardwired, it doesn't pay off in all cases. Some instructions are so infrequent and not performance critical that it makes no sense to hardwire them, but instead use a bunch of other instructions to emulate them. The difference is that in modern CISC CPUs, all instructions must be translated, whereas in modern RISC CPUs, the CPU designer can choose when to hardcode an instruction, when to translate an instruction, and when to use a hybrid model of both. And even that is a level of flexibility that IMHO speaks for RISC.
@@xcoder1122 The thing about cyber security is that nowadays we're WAY past the point where you can design a system simple enough that it's easy to design it bug-free. I agree with you that unnecessary complexity is a sure-fire way to introduce more bugs/vulnerabilities but no system is ever 100% safe (well, I guess if it's broken and doesn't work anymore then it's safe... but then it's also broken and doesn't work anymore).
Many of these abstraction layers are there simply to make it harder for malicious actors to run arbitrary code on the hardware. The most obvious example I can think of is separating programs running on the kernel from userland programs. Is this abstraction layer really necessary at the end of the day? No, not really. Does it make your system more secure? Yes, it does.
While this isn't the reason why the translation hardware exists in x86, I thought it was interesting that it could be leveraged for additional security (your example of the unfixable M1 CPU vulnerability was a good example of how the x86 translation hardware makes x86 CPUs *potentially* more secure).
RISC vs CISC doesnt matter anymore, all modern high performance chips even the "RISC" chips simulate some or all of the ISA in microcode because GBOoO is a massive Performance increase and more stable than implemcenting Out of Order execution in the operating system.
Also M1 uses microcode and a firmware, it has 8 instruction decoders with thumb-2 support and support for SVE2, the "controversial at the time" CISC-like and variable-length instructions that speed up tasks like media encode/decode on ARM by over 800% since those hit the load-store bottleneck extremely quickly and benefitted greatly from microcode. Even on X86, 14-18 instructions are hardwired depending on the CPU, just x86 makes heavier use of traditional microcode for now.
@@ghost-jesus You named the difference yourself. " even the "RISC" chips simulate some" - but not all. If you look at Apple's ARM CPU design, you'll notice that in fact most arithmetic instructions are in fact pure hardwired silicone. x86 on the other hand has not a single instruction of that kind, it cannot have such instructions as the core doesn't know anything about x86 ISA, it speaks a different language for ages and x86 instruction are no longer suitable to even be hardwired. Even if you would want to do that, there is no chance you could still do it.
And that's also what I wrote. I did write that some RISC instructions are not hardwired, didn't I? I did say that the M1 has a firmware, didn't I? Why do you think you are contradicting me by just repeating what I already said before? But I also pointed out that not all CPU instructions are controlled by firmware, otherwise Apple could fix this one security design flaw that is known for M1 and they cannot as no firmware is involved in the instruction leading to this issue.
And 8 instruction decoders with thumb-2 support has nothing to do with the topic at all. Instruction decoders do no translate instructions, they decode (hence the name) instructions, which means thy forward the instructions to the correct processing unit and make sure this unit is in the right state to perform the operation. All of that can be done purely in hardware if desired, no firmware or translation necessary. Also thumb-2 can be implemented 100% in hardware if you want to, as all thumb-instructions can be mapped to non-thumb ARM instructions purely by only by interconnecting conductors.
Again, it's all about what can be done vs what must be done. x86 must be translated and handled by firmware, nothing else is possible anymore. ARM doesn't force you to ever do that. It's totally up to the CPU designer if they want to do that, where when and for which instruction that want to. And this means a lot of flexibility and flexibility is good, as it leads to better designs compared to compared to being constrained by a framework from the outset.
You need to understand what the OSI model is, understanding the basics in coding.
good luck ;)
microsoft is killing x86 ecosystem right now by outdating old intel and amd processor which will run win 11
The background music is annoying
no it doesn't. Enjoy your electricity bill
No, it doesnt matter, ARM has always been shit.
Windows will die on x86-64 unless Microsoft forces the change like Apple. Emulation is not perfect and this will make ARM always second place on PC.
So, hmmm...... x86 better?
159th subs!
I think I’m 160
Worst background music ever
The loud "jazz" music makes this unwatchable.
TLDR?
People still listen to jazz???????????
This comment hurts more than any insult one could give. My poor heart 😭 . . . I know I poorly edited and mixed this video, but Jazz is AMAZING!
Please go listen to the Quasimode "Land of Freedom" Album. It's quintessential for anyone even slightly curious about the genre. Basically "required reading" my friend.
Jazz will change your life! 🎵🎺🎷🎹🎶
@@SiliconFox-s8d nah fam, I hate jazz. I listen to Chill Out electronic. I grew up with a jazz enthusiast father. Can't stand jazz. Loved your video though.
@@SiliconFox-s8d As someone getting more and more into jazz, I appreciate you adding it in the video!