High CPU usage for a core, process, or thread, does not necessarily mean that game is actually doing anything important/significant with that core which would benefit from more of them / faster cores: because sometimes "Core #1 Usage: 99%" actually means it's not really doing anything except waiting for something on "Core #0" to finish.
In programming, there is what is known as a "blocking wait", meaning instead of freeing up resources (sleeping) while waiting for something else (usually I/O like disk access, network data, etc., but can also be simply waiting for another thread to finish). Blocking waits are generally bad because they can lead to problems like mutual exclusions and eventually deadlocks; however, the OS, not the program, is the main one in charge of preventing deadlocks, and dealing with stuff like proper thread synchronization is pretty damn tricky (to pretty goddamn tricky). Remember that graphics developers' main goal is to make a prettier, more immersive, and more functional experience, and a game developer's main goal is to make a fun and profitable game, etc.: optimization often takes a back-seat except where it's clearly multi-platform safe. And tricks like blocking waits can make thread synchronization a heck of a lot easier and/or safer.
You may notice in your Windows Task Manager you'll have the "System Idle" process usually taking up most of your CPU resources, which is indeed a process -- one that continually sends commands to the processor in a loop -- most often, the HALT (HLT) instruction in modern times, maximizing power-savings. Games with blocking waits on the other hand, not being coded anywhere near the level of operating systems (and for multi-platform or portability reasons), will most often be compiled to use an instruction like NOOP (No Operation) to give to the processor, along with possibly some overhead instructions it'll do while waiting. While both the hardware and OS can sometimes optimize power usage for instructions like NOOP, it'll still show up as high CPU usage for that thread/process.
Those that are old enough / cared enough back then may remember John Carmack was trying to explain partly this, along with the general immaturity of multi-threading at the time, when he was asked multiple times why Doom 3 wasn't optimized for multicore; and why his answer seemed to indicate that "multicore isn't important for gaming [at this time]". Not to say it isn't, but to say that all the marketing hype of games -- especially multi-platform games -- "optimized for quad-core" and "optimized for multi-core multithreading" -- is more likely marketing bullshit with some poor attempt at multithreading going on, than a serious multicore/multithreaded innovation.
That said, the newest generation of x86 multicore, thread-loving APU (CPU+GPU) gaming consoles may bring about real, serious innovation in multithreaded gaming.
In programming, there is what is known as a "blocking wait", meaning instead of freeing up resources (sleeping) while waiting for something else (usually I/O like disk access, network data, etc., but can also be simply waiting for another thread to finish). Blocking waits are generally bad because they can lead to problems like mutual exclusions and eventually deadlocks; however, the OS, not the program, is the main one in charge of preventing deadlocks, and dealing with stuff like proper thread synchronization is pretty damn tricky (to pretty goddamn tricky). Remember that graphics developers' main goal is to make a prettier, more immersive, and more functional experience, and a game developer's main goal is to make a fun and profitable game, etc.: optimization often takes a back-seat except where it's clearly multi-platform safe. And tricks like blocking waits can make thread synchronization a heck of a lot easier and/or safer.
You may notice in your Windows Task Manager you'll have the "System Idle" process usually taking up most of your CPU resources, which is indeed a process -- one that continually sends commands to the processor in a loop -- most often, the HALT (HLT) instruction in modern times, maximizing power-savings. Games with blocking waits on the other hand, not being coded anywhere near the level of operating systems (and for multi-platform or portability reasons), will most often be compiled to use an instruction like NOOP (No Operation) to give to the processor, along with possibly some overhead instructions it'll do while waiting. While both the hardware and OS can sometimes optimize power usage for instructions like NOOP, it'll still show up as high CPU usage for that thread/process.
Those that are old enough / cared enough back then may remember John Carmack was trying to explain partly this, along with the general immaturity of multi-threading at the time, when he was asked multiple times why Doom 3 wasn't optimized for multicore; and why his answer seemed to indicate that "multicore isn't important for gaming [at this time]". Not to say it isn't, but to say that all the marketing hype of games -- especially multi-platform games -- "optimized for quad-core" and "optimized for multi-core multithreading" -- is more likely marketing bullshit with some poor attempt at multithreading going on, than a serious multicore/multithreaded innovation.
That said, the newest generation of x86 multicore, thread-loving APU (CPU+GPU) gaming consoles may bring about real, serious innovation in multithreaded gaming.
Last edited:
Facebook
Twitter