Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new speed milestone for Chrome

blog.chromium.org

Post reply on HN
Print view View original

61–70 of 161 posts

Re: A new speed milestone for Chrome

#61

Post by austincheney »

Traster wrote: post #59

I'm a little confused as to what the actual milestone is here? "We got 13% faster vs our last build" is just... well.. every day. I thought there was going to be some specific metric that they beat. It's good that browsers get faster at specific benchmarks, but what we basically always see is that the web gets more complex whilst browsers get faster (this is just an extension of the effect where software gets more co…

It’s more subtle and monumental than that. Before this JS was already executing at the same speed as Java except for in arithmetic. At this rate of improvement eventually JS will execute much faster than Java in all areas except arithmetic where it will achieve near parity.

I am not seeing any other programming language continuously improve their execution speed this much.

Re: A new speed milestone for Chrome

#62

Post by codedokode »

I think that browser developers are optimizing the wrong thing. Specifically: they optimize for execution speed while they better optimize for minimum memory usage instead. Let me explain why this is more important.

Let's say I am visiting a properly made website and it takes 10% of CPU to render. Even if browser devs make their browser twice faster, it will only save 5% of CPU time - and that would be completely unnoticeable. You might ask, what about modern websites, built with D*t compiled to webassembly, GPU acceleration, reactive frameworks, material design and capable to load the multi-core CPU at 100%? I am not using such sites so I don't care.

Now let's look at memory usage. Optimizing for speed usually causes increased memory consumption, and this increases the chance of invoking swapping. If the system starts swapping, it becomes orders of magnitude slower. No speed optimizations will matter in this case.

Therefore if you are targeting wide audience, and not only mac users, then you should be optimizing for memory usage. If the browser could use two times less memory while using twice amount of CPU time that would be perfect. Just think how many laptops with 2 or 4 Gb of RAM would become usable again.

Re: A new speed milestone for Chrome

#63

Post by jart »

kevingadd wrote: post #46
jart wrote: post #40

Earlier quoted context omitted.

Here's a conundrum. Fabrice Bellard's QuickJS engine takes 3 minutes to run the test262 ECMAScript conformance suite. d8 takes 37 minutes to run test262 according to https://medium.com/compilers/testing-the-v8-javascript-engin... and it crashes for me in Chrome https://v8.github.io/test262/website/default.html Has anyone else observed this performance disparity? Could it really be possible that a JavaScript engine wr…

Are you sure they're running the same set of tests? There's over 10000 tests in the full set that webpage runs, but there are subsets and fabrice might be running one of the subsets. FWIW test262 falls over partway through in Firefox and I have to kill the tab, though it doesn't crash. There are a bunch of test failures as well for things that are probably not implemented by anyone (I'm curious how many of the tests…

V8 has 89% coverage and QuickJS has 86%. https://test262.report/?date=2022-02-28

Re: A new speed milestone for Chrome

#64

Post by Cthulhu_ »

aaronbrethorst wrote: post #35

Cool to hear that Chrome is faster than Safari, but that's not why I'm going to stick with Safari. I use Safari because of Chrome's memory bloat, Safari's text message MFA auto-fill features, and Safari's cross-platform (iOS/macOS) password manager.

I'd probably use Safari more if it wasn't for me being used to Chrome's dev tools. Safari is a lot less resource hungry, artificial benchmarks aside.

Re: A new speed milestone for Chrome

#65

Post by Talanes »

saagarjha wrote: post #45
eyelidlessness wrote: post #32

Earlier quoted context omitted.

Chrome's pooling model seems to improve system performance as you say (and as I was trying to express), at high pressure. Safari’s model seems to optimize for low system pressure by favoring spawning more processes. Individually they perform better, but overall it degrades as process count increases.

Lowering system pressure is basically the same as improving system performance, so I guess I'm still not understanding what you're trying to say.

I believe pressure here is referring to the workload being asked of the machine, rather than the result of how it is processing that workload.

Basically: More Tabs = Pooling is more performant, less tabs individual process is more performant.

I don't know how true that is, but I'm fairly certain that is what GP is trying to get across.

Re: A new speed milestone for Chrome

#66

Post by [deleted] »

whizzter wrote: post #51
jart wrote: post #40

Earlier quoted context omitted.

Here's a conundrum. Fabrice Bellard's QuickJS engine takes 3 minutes to run the test262 ECMAScript conformance suite. d8 takes 37 minutes to run test262 according to https://medium.com/compilers/testing-the-v8-javascript-engin... and it crashes for me in Chrome https://v8.github.io/test262/website/default.html Has anyone else observed this performance disparity? Could it really be possible that a JavaScript engine wr…

test262 is a conformance test and as such mostly runs small test-snippets once to verify, what counts here is setup, parsing and first-run execution. While V8 has added a fast first-stage interpreter there are probably a ton of other overheads when starting a V8 context as well as "inefficiencies" related to preparing code for later JIT optimizations. So for more CPU intensive code written in JS where the JIT activat…

[deleted]

Re: A new speed milestone for Chrome

#67

Post by mort96 »

jart wrote: post #40
greggman3 wrote: post #17

There are certainly lots of situations where one browser beats another For example in this microbenchmark, Chrome is 10x slower than both FF and Safari at one method. https://jsbenchit.org/?src=cfcb916dd03df45952183e6484a14344 Here's another where in one case Firefox is 54x faster than Chrome https://jsbenchit.org/?src=beb26575ad78caa99a2a8c45ce2b780f

Here's a conundrum. Fabrice Bellard's QuickJS engine takes 3 minutes to run the test262 ECMAScript conformance suite. d8 takes 37 minutes to run test262 according to https://medium.com/compilers/testing-the-v8-javascript-engin... and it crashes for me in Chrome https://v8.github.io/test262/website/default.html Has anyone else observed this performance disparity? Could it really be possible that a JavaScript engine wr…

I wrote a small lisp in Rust. I try to not do obviously stupid things, but it's just a basic parser + AST interpreter; its execution speed is slow compared to even a basic bytecode interpreter, and it's absurdly slow compared to a JIT. Yet it runs hello world in a fraction of a millisecond, whereas V8 needs tens of milliseconds.

In executing one computationally intensive program, V8 would be many orders of magnitude faster than my program. But in a test which largely consists of running tens of thousands of small, uninteresting test case programs, my silly interpreter would outperform V8 by orders of magnitude.

Essentially, performance is complicated, and improving throughput often has costs in other areas.

Re: A new speed milestone for Chrome

#69

Post by wwtrv »

codedokode wrote: post #62

I think that browser developers are optimizing the wrong thing. Specifically: they optimize for execution speed while they better optimize for minimum memory usage instead. Let me explain why this is more important. Let's say I am visiting a properly made website and it takes 10% of CPU to render. Even if browser devs make their browser twice faster, it will only save 5% of CPU time - and that would be completely unn…

The laptops with 2 or 4 Gb of RAM (e.g. Chromebooks) are also likely to have Celeron or MediaTek CPUs which might struggle much more than that, also unless you have multiple tabs open 4GB of RAM might not be that bad.

And given a choice between being able to open several tabs all of which are barely functional and being stuck on a single website at at time which runs smoothly I'd definitely choose the later (of course the tradeoff is probably not as straightforward, then again it's not completely obvious to me that optimizing for speed would necessarily result in higher memory consumption).

IMO even if they are optimizing for Macs, I'm not sure this approach would make sense (assuming the tradeoff between CPU performance and RAM usage exists) since they are much more likely to have less memory and better CPUs than PC laptops (e.g. you can probably easily get a Windows laptops with 32GB for $1000 or less).

Post reply on HN