The CPU doesn't run all cores at full speed because of how tasks are managed and limited by hardware design.
The CPU doesn't run all cores at full speed because of how tasks are managed and limited by hardware design.
I store a lot of data and typically rely on my 3080 for speed boosts, yet the file size remains large. When I need a smaller output, I switch to CPU-only (Ryzen 9 5900x). Why do different cores behave differently? Also, using PBO with a temperature setting around 70°C and the curve optimizer doesn’t seem to push performance much higher. I’ve heard some claim they reach 5GHz on all cores, but my tests show otherwise. During benchmarks, a few cores can hit around 4.8GHz, but sustained tasks reveal limitations.
Unfortunately, core scaling doesn't keep improving without limit. Based on what I've seen, 12 cores—whether logical or real hyperthreaded—start showing slower gains for handbrake. My 2600X handles around 4.95 across all threads quite well, though it hovers near the thermal cap mainly due to limited airflow in the stock cooling setup.
The file size/bitrate depends on the bitrate, not encoding or CPU/GPU power. You can define a wide range of bitrates for each encoder. Which application are you employing? What configurations are applied? How fast is the output?
Using identical configurations with hardware support reduces the file size considerably compared to when processing without acceleration. For example, a 28GB MKV processed with hardware acceleration on your 3080 results in a 6GB file, whereas CPU-only processing yields only 2.5–3GB. This difference is noticeable when using Handbrake.
Settings such as "Constant Quality" rely on higher bitrates with hardware encoding, since the hardware encoder delivers lower quality at those bitrates. Using constant bitrates keeps the file size the same but changes the image quality. Each codec has its own optimization approach. I’m not familiar with the latest AV1 details, but it seems compression was quite strong previously. If you want smaller files and your platform supports it, it might be worth a try—though performance could be slower.
It's a clear point: performance mainly hinges on the software rather than your CPU. Optimization can be tricky, especially with multi-threading, and some developers might have better ideas. Handbrake hasn't delivered noticeable improvements for me either—its output often appears grainy even at high settings.
Your processor has 12 cores fully utilized. The hyperthreading units don’t reach full capacity and that’s okay. In a very basic sense, hyperthreading threads only handle tasks when other resources aren’t busy—like if each core has several functions (additions, multiplications) and the main core runs code using just one function type, the extra threads can shift unused functions to work on them instead of remaining idle. The ideal number of threads changes based on your configuration and video resolution. The encoder examines multiple frames ahead, using data from past frames to compress the current one. Some frame analysis parts can be done in parallel while others must follow one after another. If my understanding is right, for x264, aiming for top quality means keeping 1 thread per 64–80 pixels of vertical size. For a 720p video, around 10 threads would be suggested. You may increase the number, but some threads will wait or the output might slightly drop in quality, depending on your encoding choice. Consistent quality ensures stable performance throughout. In scenes with little movement, like a quiet conversation, the encoder uses fewer bits. For fast-moving scenes such as a chase or explosion, it requires more bits to maintain the same quality. One video at constant quality 22 can range from 10 GB to 14 GB, depending on the source and encoding efficiency. Various settings affect how much storage is used or needed. It begins with lossless images and evaluates what can be reduced or blurred to lower the bitrate while keeping quality steady. With x264, using --preset ultrafast and constant quality 22 might yield a 20 GB file, whereas --preset veryslow and the same quality could result in a 15 GB file—keeping quality similar but saving space. The slower preset enables deeper analysis for better compression without sacrificing much detail.