WEBVTT 00:00:00.000 --> 00:00:06.560 If I tell you I'm multitasking, don't believe me, the best that I can do as a weak pitiful human 00:00:06.560 --> 00:00:12.640 is to quickly switch my attention from one single thing to another. But is that how your CPU works? 00:00:13.440 --> 00:00:19.040 Actually, no. Your CPU relies on a strategy called scheduling, where the operating system 00:00:19.040 --> 00:00:24.480 will decide what sets of instructions or threads will get put through the CPU first, 00:00:24.560 --> 00:00:30.000 second, third, and so on. Understanding scheduling is crucial to understanding 00:00:30.000 --> 00:00:35.360 exactly how modern multi-core CPUs work. So we got a little bit of help for this video, 00:00:35.360 --> 00:00:39.200 and we'd like to thank our friends at Intel for their assistance as we run through this thought 00:00:39.200 --> 00:00:44.400 experiment. Each thread that your computer is working on gets assigned a value called priority, 00:00:44.400 --> 00:00:49.120 so a thread with a higher priority value will be further ahead in line to get processed by your 00:00:49.120 --> 00:00:55.120 CPU. Developers can assign priority values when they write a program, and Windows can change a 00:00:55.120 --> 00:01:00.080 thread's priority based on how many system resources it needs and what the exact nature 00:01:00.080 --> 00:01:05.600 of the instructions are. For example, if a thread is tied to what you're inputting with a keyboard 00:01:05.600 --> 00:01:10.720 and mouse, such as clicking buttons in your web browser or aiming your weapon in a game, 00:01:10.720 --> 00:01:16.080 it's likely going to get a higher priority. By contrast, background activities that aren't 00:01:16.080 --> 00:01:21.920 time sensitive, those will get a lower priority. Similarly, developers can assign another value 00:01:21.920 --> 00:01:29.200 called quality of service, or QOS, to each thread. QOS is a way for devs to signal to Windows 00:01:29.200 --> 00:01:34.080 how much processor power a thread might need, and while Windows doesn't treat it as important 00:01:34.080 --> 00:01:39.440 as priority, QOS is still a factor that the operating system will take into account when it 00:01:39.440 --> 00:01:45.440 comes to scheduling. QOS is especially relevant when it comes to power management, as the OS can 00:01:45.440 --> 00:01:51.440 use QOS to request a certain frequency from the CPU, and the CPU's hardware can decide 00:01:51.440 --> 00:01:56.640 if it can ramp up to that frequency while staying within power limits. That's especially useful 00:01:56.640 --> 00:02:04.000 on laptops. Which is all very cool, but in terms of our guy doing two things at once analogy, 00:02:04.000 --> 00:02:10.640 priority and QOS pertain more to what I'm choosing to do, like texting while watching a movie, 00:02:10.640 --> 00:02:17.440 rather than how I'm juggling those two tasks. So let's drill down into that. Traditionally, 00:02:17.440 --> 00:02:24.000 CPU threads would go through one at a time, like my brain, but this isn't how modern multicore 00:02:24.000 --> 00:02:29.760 systems operate, especially considering some newer chips even have different kinds of cores 00:02:29.760 --> 00:02:36.080 all on one package. One goal in scheduling on multicore is not to context switch more than is 00:02:36.080 --> 00:02:42.560 necessary. And context switching is just another fancy term for moving a thread from one core 00:02:42.560 --> 00:02:48.800 onto a different one. In general, you want each thread to start and finish on one single core, 00:02:48.800 --> 00:02:53.440 and you want to load balance across cores so that none of them are getting overwhelmed. 00:02:53.440 --> 00:02:57.680 And there's been a lot of tweaking over the years to figure out how to do this easily 00:02:57.680 --> 00:03:03.200 and efficiently, such as with libraries, which are software resources that sit between the 00:03:03.200 --> 00:03:08.320 program and the operating system and allow multi-threading without making a developer do 00:03:08.320 --> 00:03:14.720 a ton of extra coding. On newer chips, how exactly threading works out across cores becomes even more 00:03:14.720 --> 00:03:20.960 important because of hybrid chips like Intel's Alder Lake lineup. These chips have higher performance, 00:03:20.960 --> 00:03:28.800 or P cores, and lower performance, but more power saving, E cores. It might be confusing as to why 00:03:28.800 --> 00:03:33.440 they put E cores on a desktop CPU where you aren't worried about your battery running out, 00:03:33.440 --> 00:03:38.880 but because E cores are physically smaller, you can actually pack more of them onto a chip, 00:03:38.880 --> 00:03:44.880 meaning you can in some cases get better performance if the scheduler can spread a program out 00:03:44.880 --> 00:03:50.720 across many E cores compared to a smaller number of P cores. Now, even though the Windows scheduler 00:03:50.720 --> 00:03:57.280 will still use P cores first by default if they're not busy, it can then use an E core for a second 00:03:57.280 --> 00:04:03.520 thread before using the slower hyperthreading feature of a P core. We're also getting to the 00:04:03.520 --> 00:04:08.080 point where, although Windows is still making final decisions on scheduling, there are now 00:04:08.080 --> 00:04:15.040 hardware assist features on newer CPUs that will actually give advice to Windows, so a CPU can look 00:04:15.040 --> 00:04:20.960 at the incoming workload and then advise Windows on the best current core for a certain thread, 00:04:20.960 --> 00:04:25.040 depending on whether Windows wants more performance or better power efficiency. 00:04:25.600 --> 00:04:31.040 So there's a lot that goes into deciding who gets to go first when it comes to your CPU, 00:04:31.040 --> 00:04:37.680 and a multi-core model can legitimately multitask. Also, my wife can do it somehow. 00:04:37.680 --> 00:04:44.160 If you guys enjoyed this video, check out our other videos, leave a comment if you have a suggestion for a future fastest Techquickie, 00:04:44.160 --> 00:04:45.520 and don't forget to subscribe.