Probably because video encoding is one of the most demanding CPU tasks. When not hardware-accelerated, it’s incredibly taxing on a system, as it involves gargantuan amounts of data and processing. (We use compressed formats that have staggering compression ratios. The raw data the encoder needs is huge, and the amount of processing needed to achieve high compression is insane.)
The typical things most people do most of the time (web browsing, watching videos, creating documents, etc) simply aren’t demanding enough to tease out meaningful performance comparisons.
I remember back in the early 90s, when computer benchmarks ran massive scripted suites of real-world software, that one common benchmark item was how long it took a spreadsheet (originally Lotus 1-2-3, later Excel) to recalculate a spreadsheet with a couple of thousand cells. (Not lines. Cells.) They had to increase the size of the spreadsheets to keep up with performance improvements, before eventually abandoning that test because all computers got fast enough that recalculating a spreadsheet became instant, so they just made it automatic as we know it today. (IIRC, we got to the point in those tests that they couldn’t even increase the test spreadsheets, as they’d reached the limits at the time of how many columns and rows you could have; that is, limits written into the code, not computing resource limits.)
Well, i was recently using Excel to quickly plot some CSV data and once you get to >100k rows things start to really slow down. I had cases where excel would lock up for >30 seconds at a time after pressing a button to munch away at data. Admittedly this was like a >30MB CSV file but still, modern computers should handle that (There are now CPUs that could fit the whole file in cache even). Most of the reason is just that excel is not very well optimized for dealing with large amounts of data and is bogged down by 30 years of legacy code under the hood.
For sure. Over the years they've increased the sizes of data sets it can work with, but it definitely doesn't mean it's optimized for them. (This is also the one area where 64-bit Office actually makes a difference, supposedly.)
Since I really only use Excel to do things like BOMs and other such non-number-crunchy data, it's not something I've ever had to wrestle with!
But yes every synthetic benchmark has a bias towards something. Not everyone uses a computer to do the same thing. There is nothing that makes Cinebench particularly superior to other benchmarks, but its workload of raytracing on CPU is still a pretty well-balanced load that stresses all of the modern CPUs functionality. It involves a good deal of math computation for all those vectors, it involves heavily branching code that tests the pipelines agility, it consumes a fair bit of RAM bandwidth due to the size of data, it's easily parallelizable so that it can make use of pretty much any number of cores... etc So this means it includes most things that CPU heavy applications would need and so the resulting score number is a reasonably good indicator of overall performance.
Exactly!
There isn't one benchmark that can make everyone happy, since that's literally impossible, given people's competing needs. But few everyday tasks can actually push a modern system anywhere close to its limits.
As for parallelization: this is a point I think most people don't really understand. I don't think most people realize that for most tasks, it's single-core performance that matters, since a) not all things can be parallelized, and b) parallelizing code is
fucking hard to get right. (I think it's actually something most developers are not capable of doing well.) For everyday things, going from a single core to dual core made a big difference, since the second core could handle OS housekeeping while leaving a whole CPU core to the user app. But every core beyond two delivers only insignificant performance increases for everyday apps whose performance is ultimately bound by one thread, even if some things are offloaded to separate threads (like video playback, or indexing, etc).