Hacker News Reader

Comment by la_barba | Hacker News Reader

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...

View on HN

> 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).

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

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!

Reply on news.ycombinator.com