Not really all that surprising. i3 is Coffee Lake, i9 is Skylake. Even clock-for-clock, the process possibly improved enough for a slight IPC advantage to the i3.
The 2% here is heavily weighted on single-core performance and the results are IMHO what one would expect from these two parts (the moment more than four cores are in a test, the i9 wins by a mile).
Also, the Reddit link posted seems to be all about a whole different side of the discussion (the calculation changes at userbenchmark, AMD/Intel favoring, etc).
Yes, that new algorithm disproportionally disadvantages AMD CPUs which are largely about multi-core performance. The new score weighting basically ignores the main advantages of the Ryzen series.
I'm curious if they're just catering to their most common readers. If they have a high percentage of people that use the site that use workloads where single-core performance or low-count-multi-core performance is most important (gaming, apps that take advantage of 4 cores but not 18, etc) then maybe they thought that their algorithm originally favored Ryzen too much, and this is a balancing correction, not a favoring of Intel?
Also, I don't understand the uproar over one small little overall percentage number- the rest of the numbers are there for anyone to easily weigh one against the other. Just a few lines down it's clear than the 18-core part demolishes the 4-core part in multi-core workloads (as anyone would expect without even visiting the website in the first place).
Being able to handle more programs at a time/etc really has no bearing on "effective speed"- if their workloads are not apps that take advantage of 18 cores (encoders, etc), it's possible a 4-core part could "feel" just as fast, or faster, than an 18-core part if it does their workload faster.
That said, the whole AMD/Intel war is less important to me because fanboyism in any amount is toxic and worth avoiding. People biased heavily enough towards one company will always see anything like this as some kind of conspiracy or attack, regardless of whether or not it's true (something I don't know in this case)
What do you most people use their computer for? Web browsing, word. Maybe some foto or video editing. With the exception of word all of these things MASSIVELY gain from having lots of cores. Not sure where the myth that most people have single threaded workloads comes from because it's not true at all at this time.
I don't think its true that most people do web browsing. Its just an easy generalization to make. The world has thousands of industries and each specialty domain has their set of software suites that they need for their business. In my industry (pharma), and I'll adda caveat here that I haven't done a rigorous scientific analysis of every single workload, but off hand, all of our software is heavily dependent on single-thread perf. To be sure, there is some stuff that benefits from multiple cores.. dna sequencing/alignment/processing comes to mind, primarily because we're processing hundreds of GBs of data. But by and large, I would pick a CPU that has better single-thread perf. For our accounting folks who use quickbooks a lot, are not going to benefit "massively" from a high core count. For our facilities team that uses autocad.. again same thing .. I don't find a massive benefit from 10-12+ core systems. Sure you can always on a case-by-case basis invent scenarios which could potentially benefit from more cores, but this massive gain across the board that you claim is a bit of an exaggeration. IMHO/IME/YMMV/$0.02 etc..
99% of single threaded industry software doesn't need more power. That's why all of these cheap office pc have i3 processors that are years old. Single threaded performance has only one real advantage at this time and that is gaming.
I think multi threading performance is way more important in the real world.
>99% of single threaded industry software doesn't need more power.
Again, I don't know if that is true. I'd love to see stats on that. My gut tells me improved single-threaded perf will always be welcome in most software because most data transforms are not not easily parallelizable. Certainly for me, more single threaded perf is always welcome in all the software I use daily.. from office suites to compilers to IDEs to photoshop to soft-PLCs/SCADA/HMI or even when opening a super large excel file with crazy forumlas. I don't think its just gaming.
The specifications of budget/cheap computers are not really an indicator of what will or wont benefit from single-threaded perf. Whether the benefit is worth paying for will obviously depend on other factors. For me its a nobrainer.
In what world would going from 4 cores to 18 cores even remotely matter for web browsing? If you notice a difference in >4 cores for web browsing (and maybe it IS noticeable and I just don't realize it)... then the web's even in a sadder state than I thought. Anecdotally, I had about 20-30 tabs open yesterday on a four-core machine, a couple of those I was actively using (one playing a video), and CPU usage was maybe 25% or less.
Photo/video editing on the other hand will DEFINITELY see a benefit, something I agree with- but I doubt nearly as many people do this as one would think- and again, it's clear from userbenchmark's page of data that the 18-core part in these workloads would demolish the 4-core part...so I don't see a problem.
I guess everyone just can't let go of what the "effective overall speed" number/percentage means. Maybe it's better not to have an "overall number" in the first place, since it can never always be true and is too dependent on the user? I have a feeling the majority of people reading the site are going to look at more detail than a single number anyway. They're certainly more likely to be gamers and/or enthusiasts
Ever since users could open multiple tabs at once and web pages could be active in the background, along with everything else that's running on the machine in the first place.
If single-core is all that's important, why are AMD and Intel coming out with multi-core chips at all and why are people buying them if they don't see any improvement?
It's less about single-core vs. multi-core, and even then, it's really not about quad-core vs more-cores.
My thought pattern through all of this (and maybe I'm completely off base) is that, for instance, having a 4-core part with high single-core performance might be preferable to a gamer/enthusiast (depending on common workloads) than an 18-core part with less single-core performance, and that maybe this is all a reason to consider why the weighting of UserBenchmark's "overall" score changed instead of immediately attaching the change to some anti-AMD bias
Maybe my idea that the most common workloads of UserBenchmark users (I don't claim to know their demographics, but I figured one could make assumptions based on the types of individuals that would look up benchmarks in the first place- very common among gamers) would see diminishing returns after, say 4 cores, is wrong- but that was how my thought process was going.
And a related point I'll concede (I admit my thinking maybe is just too old-school, biased, too filtered through my own experience and needs updating) is maybe there are more games and programs than I thought that actually take advantage of more than four cores.
<2 points of the difference is due to 2 generations of improvements on IPC, the other ~6 are due to the boost clock rate being 200 MHz higher from manufacturing refinement.
Counting 58% for four cores yet only 2% for >4 cores in effective speed is nothing short of an outright lie. And this change coming 2 weeks after benchmark results that put Ryzen ahead in multi-core and value proposition.
What is the "outright lie" here? Its their opinion on what they think is important for the needs of their audience. Taking advantage of so many extra cores by a single process is not all that easy or common. In a multi-process scenario the extra cores are obviously very useful. A person intending to buy a CPU for server loads would look at the appropriate benchmarks...
> Taking advantage of so many extra cores by a single process is not all that easy or common.
Browsers are both multiprocess and multithreaded. The ability to run a few webapps without having your system drag to a halt is a feature that's important to essentially everyone.
>The ability to run a few webapps without having your system drag to a halt is a feature that's important to essentially everyone.
Webapps such as? I have a 4 core CPU from 2014 (i7-4790K) and I can't recall that ever happening to me. Primarily because any modern OS will throttle crazy runaway threads to ensure UI responsiveness, so the system doesn't 'drag to a halt' as you claim.
Also honestly.. how many people are looking at CPU benchmarks to run browsers better? I'd wager a twenty that its mostly gaming nerds who are obsessed with CPU benchmarks. Then.. its also a question of knowing your audience. I'm sure they have a better idea of who their audience is than you or I.
Gmail is the #1 culprit for completely locking some of my lesser systems (i5-7200U). I also have the fun thing sometimes where opening a large PDF or Google Doc can take an unreasonable amount of resources from the rest of the system for processing. I had Facebook do it constantly for a period where I made the bad decision to use it for a while. I find a good bit of information from benchmarks for non-desktop processors/whole system configurations, especially when a new feature set/generation swings the difference between an i3 and an i5 for instance.
"Primarily because any modern OS will throttle crazy runaway threads to ensure UI responsiveness" seems like you have a particular OS in mind, and I would be interested in hearing more. I do not observe that behaviour on Debian 9 (and other Linux distros), Mac OS X, and Windows 7/8. I regularly bring any of those to UI stuttering/freeze from various workloads. Webapps only really breaks the lesser ones singlehandedly though (most of my other systems are 4+ core with 32GB+ RAM).
Well.. I don't know what to say, I guess you should report those bugs to the appropriate vendors then. I don't believe a memory leak means we tell people to buy more memory :)
>"Primarily because any modern OS will throttle crazy runaway threads to ensure UI responsiveness" seems like you have a particular OS in mind, and I would be interested in hearing more.
Sure. You should read up about thread scheduling and how an OS scheduler works. I don't think I can explain that in a comment, and I'd do a poor job anyway.
>I do not observe that behaviour on Debian 9 (and other Linux distros), Mac OS X, and Windows 7/8. I regularly bring any of those to UI stuttering/freeze from various workloads. Webapps only really breaks the lesser ones singlehandedly though (most of my other systems are 4+ core with 32GB+ RAM).
CPU utilization is an extremely poor indicator for whether or not your system will feel stuttering or freezing. What makes your system freeze is having more tasks to complete than can be reasonably scheduled in a time frame to as to appear continuous/realtime. Most OS schedulers that I am aware of do not provide special treatment to UI processes and defer to the fact that most modern UI's require many programs to respond in a timely fashion to provide a user interface and do not assign priority unless specially instructed. Most provide (relatively) even priority and have high priority interrupts like Window's ctrl-alt-delete and higher priority to kernel threads.
In Linux actual scenarios for stuttering/freezing are generally represented as a load average >1, and stuttering for me generally starts to happen when I get above 3 and I assure you no Linux system will work without observable stutter when you start getting into the 20+ load average range.
In earnest I have no idea why you tried to use a JavaScript based benchmark to support your point. Even after observing it the number of nonvoluntary ctxt switches barely even registered from baseline, probably from the variety of ways browsers do their own internal threading strategies. I could not see how to change that JavaScript benchmark to make it actually provide an interesting load on my system, so I'll just leave it at that.
I have no idea what happens under the hood in Linux, but I have never observed my Linux desktop 'crawling to a halt' because of some silly webapp. This is normal expected behavior. I know for a fact that ensuring responsiveness of GUI apps has been in the NT scheduler for decades. Look up dynamic priority groups. There is really no point rehashing and arguing over basic design issues that anyone can lookup and as such this thread is not really productive for either of us. Hope you have a nice day, Goodbye!
So the 18 core chip is 5.48 times faster than the 4 core chip in multicore performance and it has almost the same single core performance as a i3 chip which is purely optimized for single core performance. Just by looking at the core count you would expect it to have 4.5 times the performance. Very impressive.
It's either not a linear scale with the 1 or 4 core benchmarks or just plain incorrect. Treating it linearly results in the paradox that at stock the 18 cores each run significantly faster than if 1 core were running. This is the opposite of what the boost algorithm would do. The quad core scores seem reasonable though, just mildly lower per core than the single core bench.
Can't somebody just invent a pluggable PC architecture, ala Kubernetes?
So you would connect several PCs, notebooks to a switch, or by wifi, then you run a desktop, gnome or something, but there's a layer, heck it can be even a wrapper before running the binary.
The layer or the wrapper would just check how's going your load, memory and would the app from whatever machine has enough free resources available, the it would show you a window with you app running there (in a PC/notebook different from you "main" one), as fast as the network connection you're using to cluster up your assembled PCs / notebooks.
I think Xwindow and some go code could do the trick? There's some experience sharing clipboards/mouse/keyboard input (synergy).
What would be really necessary is a scheduler ala kubernetes (but a somewhat clever bash script could the job as well), to be able to orderly tap the free resources in several connected PCs/notebooks.
No need to rewrite thousands of apps, or design a new desktop environment completely from scratch, and you could actually would be able to run Chrome in its own hardware, just to use a hundred of tabs if you feel like to do it
29 comments
[ 5.1 ms ] story [ 95.8 ms ] threadAlso see discussion on reddit: https://www.reddit.com/r/hardware/comments/chaofa/psa_userbe...
The 2% here is heavily weighted on single-core performance and the results are IMHO what one would expect from these two parts (the moment more than four cores are in a test, the i9 wins by a mile).
Also, the Reddit link posted seems to be all about a whole different side of the discussion (the calculation changes at userbenchmark, AMD/Intel favoring, etc).
Also, I don't understand the uproar over one small little overall percentage number- the rest of the numbers are there for anyone to easily weigh one against the other. Just a few lines down it's clear than the 18-core part demolishes the 4-core part in multi-core workloads (as anyone would expect without even visiting the website in the first place).
Being able to handle more programs at a time/etc really has no bearing on "effective speed"- if their workloads are not apps that take advantage of 18 cores (encoders, etc), it's possible a 4-core part could "feel" just as fast, or faster, than an 18-core part if it does their workload faster.
That said, the whole AMD/Intel war is less important to me because fanboyism in any amount is toxic and worth avoiding. People biased heavily enough towards one company will always see anything like this as some kind of conspiracy or attack, regardless of whether or not it's true (something I don't know in this case)
Again, I don't know if that is true. I'd love to see stats on that. My gut tells me improved single-threaded perf will always be welcome in most software because most data transforms are not not easily parallelizable. Certainly for me, more single threaded perf is always welcome in all the software I use daily.. from office suites to compilers to IDEs to photoshop to soft-PLCs/SCADA/HMI or even when opening a super large excel file with crazy forumlas. I don't think its just gaming.
The specifications of budget/cheap computers are not really an indicator of what will or wont benefit from single-threaded perf. Whether the benefit is worth paying for will obviously depend on other factors. For me its a nobrainer.
Photo/video editing on the other hand will DEFINITELY see a benefit, something I agree with- but I doubt nearly as many people do this as one would think- and again, it's clear from userbenchmark's page of data that the 18-core part in these workloads would demolish the 4-core part...so I don't see a problem.
I guess everyone just can't let go of what the "effective overall speed" number/percentage means. Maybe it's better not to have an "overall number" in the first place, since it can never always be true and is too dependent on the user? I have a feeling the majority of people reading the site are going to look at more detail than a single number anyway. They're certainly more likely to be gamers and/or enthusiasts
If single-core is all that's important, why are AMD and Intel coming out with multi-core chips at all and why are people buying them if they don't see any improvement?
My thought pattern through all of this (and maybe I'm completely off base) is that, for instance, having a 4-core part with high single-core performance might be preferable to a gamer/enthusiast (depending on common workloads) than an 18-core part with less single-core performance, and that maybe this is all a reason to consider why the weighting of UserBenchmark's "overall" score changed instead of immediately attaching the change to some anti-AMD bias
Maybe my idea that the most common workloads of UserBenchmark users (I don't claim to know their demographics, but I figured one could make assumptions based on the types of individuals that would look up benchmarks in the first place- very common among gamers) would see diminishing returns after, say 4 cores, is wrong- but that was how my thought process was going.
And a related point I'll concede (I admit my thinking maybe is just too old-school, biased, too filtered through my own experience and needs updating) is maybe there are more games and programs than I thought that actually take advantage of more than four cores.
Multi-Core weighting is now downgraded from 10% to 2%, single-core is at 40% and quad-core at 58%: https://cpu.userbenchmark.com/Faq/What-is-the-effective-CPU-...
Counting 58% for four cores yet only 2% for >4 cores in effective speed is nothing short of an outright lie. And this change coming 2 weeks after benchmark results that put Ryzen ahead in multi-core and value proposition.
Browsers are both multiprocess and multithreaded. The ability to run a few webapps without having your system drag to a halt is a feature that's important to essentially everyone.
Webapps such as? I have a 4 core CPU from 2014 (i7-4790K) and I can't recall that ever happening to me. Primarily because any modern OS will throttle crazy runaway threads to ensure UI responsiveness, so the system doesn't 'drag to a halt' as you claim.
Also honestly.. how many people are looking at CPU benchmarks to run browsers better? I'd wager a twenty that its mostly gaming nerds who are obsessed with CPU benchmarks. Then.. its also a question of knowing your audience. I'm sure they have a better idea of who their audience is than you or I.
"Primarily because any modern OS will throttle crazy runaway threads to ensure UI responsiveness" seems like you have a particular OS in mind, and I would be interested in hearing more. I do not observe that behaviour on Debian 9 (and other Linux distros), Mac OS X, and Windows 7/8. I regularly bring any of those to UI stuttering/freeze from various workloads. Webapps only really breaks the lesser ones singlehandedly though (most of my other systems are 4+ core with 32GB+ RAM).
>"Primarily because any modern OS will throttle crazy runaway threads to ensure UI responsiveness" seems like you have a particular OS in mind, and I would be interested in hearing more.
Sure. You should read up about thread scheduling and how an OS scheduler works. I don't think I can explain that in a comment, and I'd do a poor job anyway.
>I do not observe that behaviour on Debian 9 (and other Linux distros), Mac OS X, and Windows 7/8. I regularly bring any of those to UI stuttering/freeze from various workloads. Webapps only really breaks the lesser ones singlehandedly though (most of my other systems are 4+ core with 32GB+ RAM).
I don't observe that behavior. Just for fun I ran a CPU Stress test (https://silver.urih.com/) as I'm typing this comment. CPU pegged at 100%. Not feeling a thing... https://imgur.com/a/J0l9VaP
In Linux actual scenarios for stuttering/freezing are generally represented as a load average >1, and stuttering for me generally starts to happen when I get above 3 and I assure you no Linux system will work without observable stutter when you start getting into the 20+ load average range.
In earnest I have no idea why you tried to use a JavaScript based benchmark to support your point. Even after observing it the number of nonvoluntary ctxt switches barely even registered from baseline, probably from the variety of ways browsers do their own internal threading strategies. I could not see how to change that JavaScript benchmark to make it actually provide an interesting load on my system, so I'll just leave it at that.
Factoring in all the cores tho, the i9 performance is about 3x the i3 - but at about 9x the cost. ref: https://www.cpubenchmark.net/compare/Intel-i9-9980XE-vs-Inte...
On balance, the i3 looks like a solid chip if a bit pricey for an i3.
So you would connect several PCs, notebooks to a switch, or by wifi, then you run a desktop, gnome or something, but there's a layer, heck it can be even a wrapper before running the binary.
The layer or the wrapper would just check how's going your load, memory and would the app from whatever machine has enough free resources available, the it would show you a window with you app running there (in a PC/notebook different from you "main" one), as fast as the network connection you're using to cluster up your assembled PCs / notebooks.
I think Xwindow and some go code could do the trick? There's some experience sharing clipboards/mouse/keyboard input (synergy).
What would be really necessary is a scheduler ala kubernetes (but a somewhat clever bash script could the job as well), to be able to orderly tap the free resources in several connected PCs/notebooks.
No need to rewrite thousands of apps, or design a new desktop environment completely from scratch, and you could actually would be able to run Chrome in its own hardware, just to use a hundred of tabs if you feel like to do it
https://en.m.wikipedia.org/wiki/Plan_9_from_Bell_Labs
Everything on the network was just a mount, file system, sound, cpu, etc.