Chrome just got faster with Profile Guided Optimization
blog.chromium.org
blog.chromium.org
[0] https://firefox-source-docs.mozilla.org/build/buildsystem/pg...
Normally there's a simple make target, like chrome.pgo to create the initial binary chrome, run the testsuite with pgo or better autofdo via perf and from this create the optimized chrome.pgo. using Facebook's bolt is even better.
I have no idea about Google's byzantinian bazel tool. With make it's a simple target which automates these steps.
Would it be possible for Google to publish the profile data along with the source code to enable those who compile from scratch to have these same optimizations?
>I'm surprised Chrome wasn't already taking advantage of PGO.
They have been on windows since M53 (released in 2016), but this seems to be a better implementation and it's now for MacOS as well now.
It is rolling out with Chrome M85 on Mac and Windows.
Starting in Chrome 53, Chrome has started using
Microsoft’s Profile Guided Optimization (PGO)
technology to make Chrome up to 15% faster
on Windows.
[1] https://blog.chromium.org/2016/10/making-chrome-on-windows-f...
So it sounds like they've been using PGO for a while using MSVC, and now they've started using PGO with Clang.
They do.
https://chromium.googlesource.com/chromium/src.git/+/master/...
https://yoric.github.io/post/why-did-mozilla-remove-xul-addo...
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=418865
The all-new Firefox for Android (codename Daylight) is lightening fast, and perceptibly seems on-par with the Chrome for Android in terms of responsiveness.
What stumps me is Chrome for Android is 3.8MB whereas Firefox Daylight is upwards of 40MB.
Here's a little Wikipedia stub about Profile-Guided Optimization, for those who'd like to read more about the technique.
Math may vary depending on cost of electricity.
Did they just render the alexa top 1M sites and generate a profile from that? It would seem some bits of the codebase might only be exercised by real users (eg. touch input during a mobile game).
Did they instead gather PGO information from real users? If so, how did they do that in a way to not degrade performance too much while profiling, and maintaining user privacy (sequences and addresses of branches in some cases will reveal user data)?
> To gather this data, the nightly build process now produces a special version of Chrome that tracks how often functions are used.
It doesn't say how Chrome is exercised (what pages are loaded, what user actions are simulated) during the nightly build. It seems like it must be some kind of fixed test data.
But that at least eliminates the possibility that they're gathering the profiling data from production builds used by real users, so the privacy concerns shouldn't be an issue.
(Also note that info is from 2016, so it could have changed.)
This is nice, but I remember the pain trying make a multiplayer browser game run fine, even when you put it in a background tab. The problem is that the game had matchmaking, so players would change tabs while a match was found and for the first few seconds of the start of the game. While doing so, many of the CSS animations, sounds, JavaScript functions would be queued and all executed at once when you switched back to the tab, leading to a bad experience, or in some cases the game breaking. I assume this would only get worse with this tab throttling feature, but there are legitimate use cases where both developers and users would prefer a tab to still be running at normal speed even when not focused. We use this every day in desktop applications, where we start a game or some video encoding task and just let it run, non-throttled, in the background
You shouldn't be expecting to queue up thousands of messages from potentially hours of the tab being backgrounded and handle them all when the tab is unbackgrounded. Nor should you process all the state changes as they come in even though the tab is backgrounded - no user wants to spend data/power/cpu/battery/heat on something like that.
Imagine having GTA 5 multi-player running in a background window, you would still want to hear the other people, hear the in-game sounds so you can come back to the game if something important happens, and also not have to simulate instantly all the events that you missed when you come back.
This also reminded me that we had problems with just playing a sound when a game started to let the players know they should come back to the tab. Players complained that sometimes the game does not notify them it has started, but it was just Chrome simply not executing JavaScript anymore.
How about when a tab is backgrounded, a server continues running the game and just streams an mp3 audio stream to the users device. Most devices can stream audio with the CPU actually turned off.
Streaming audio sounds like an interesting idea, so instead of the server sending an event and the client playing a sound when that event is received, the client would constantly stream a dynamically created audio file. This solution could work, feels a bit complex as you would still have to make sure stream catches up if user has a lag spike, instead of buffering the audio (timing should still be accurate).
That being said, what it the game is single-player and there is no server? Then the client itself would have to generate the audio stream and stream it to itself, which wouldn't work if the background thread is throttled.
I would imagine you could do a "catch-up" mode -- execute the simulation at uncapped FPS till the simulation reaches parity, and turn off ui/sounds/etc during it.
Actually, if you didn't have such a mode already, I'm not clear on how the simulation would ever be able to catch up (eg most RTS's won't let you rejoin a match due to this)
In this specific case, the games only lasted 3-4 minutes each and players were also timed-out after periods of inactivity.
> Nor should you process all the state changes as they come in even though the tab is backgrounded - no user wants to spend data/power/cpu/battery/heat on something like that.
In the case of games, players do expect multiplayer games to keep running (unless it is paused, and you can't usually pause multiplayer games). Yes, I agree that the game could optimize this AFK period, for example by disabling rendering, but game events should still be triggered in real-time and notify players (with sound at least) of what's happening.
My point is, there are cases when a browser background tab should still run at 100%. Other examples: uploading a video to YouTube in a background tab, running a chess engine to get best move in a position, converting a video, etc.
How times change.
Do they depend on the stack? Ie. when called from this function, that branch is always taken. That could encourage the compiler to inline the function so it can have a faster path on the branch.
This deck can give you some idea of what the modern Intel PMU can do: https://protools19.github.io/slides/Eranian_KeynoteSC19.pdf
For the instrumentation based profiling, there are other extra information collected, like frequent indirect branch targets (e.g. virtual calls in C++, to support speculative devirtualization which again enables inlining), specific values for certain arithmetic operations that can be sped up if you know the typical value (e.g. a particular division in the code only or mostly handles power-of-2, it can be optimized to use shift if the target cpu has particularly slow division, etc, etc), or values of certain function calls (e.g. length of memcpy) that can be optimized if you know the typical value (inline/unroll memcpy instead of doing a call), etc.
Clang has what they call context-sensitive profile: https://reviews.llvm.org/D54175 which partially achieves what you're asking.
Clang also supports sampling profiler - https://clang.llvm.org/docs/UsersManual.html#using-sampling-... which gives you somewhat similar control flow profile.
...but is PGO referring to the compilation of Chrome itself, or the compilation of JavaScript on sites?
The blog post doesn't actually specify which compilation is being talked about, and page performance could obviously depend on either.
https://chromium.googlesource.com/chromiumos/chromite/+/mast...
What is missing is using dTrace profiles for other OS's. PGO doesn't lead that far. dTrace would be the best cross platform solution. It's also secure.
Either (regularized) statistical inference of branches or something like assuming a baseline usage for every branch would be necessary.
This is all significantly complex of course, so for anything that are not the consumer megaprojects of software (browsers and operating systems?), I wonder if those tools could be used as well. Perhaps there could be some automated, anonymized usage reporting that does all this work?
https://github.com/google/perf_data_converter/tree/master/sr...
The internal aggregation code, of course, is known as Bartlett.
This would come up a few more times in my career. The next time was a few years later when I was having to go through a code base removing premature optimizations for initial list size in a code base. The average length of our data had grown such that our lists were now bigger than the defaults would have been. That was added to my growing collection of "making code faster by removing code" examples.
We talk about using better algorithms instead of tweaking code with micro-optimizations but then we never talk about tuning the better algorithms. So they default to the average case or worse.
I wonder if in memory representations for compute such as apache arrow exploit this
Lus tables in LuaJIT, Hack arrays, and JavaScript arrays can use different representations depending on what is stored in them.
NYU’s SETL project also did some work on automatically identifying what data structure should be used.
IBM’s Hermes project was also working on this; I’m not sure whether they shipped it.
Safari/Webkit still the "fastest browser possible" on macOS.
Microsoft would have to do their own setup. Hopefully they do.
Firefox 505 MB
Safari 480 MB
Chrome 464 MB
*she :-)
> Chrome will literally go towards the high 70s for no fudging reason, while idle
That seems extraordinarily high, and I've personally never experienced that problem.
I think in most cases, and for most real world users, they have made the right call. And the product I'm building right now, every kilobyte of RAM Chrome uses to render my webpage costs me multiple dollars per month, and I still think the devs made the right choice.
Somehow mobile Chrome keeps opening a new tab for everything I do, and I found I had over 1000. Since the tabs aren't actually loaded unless you switch to them, I assumed keeping 1000 URL's in memory wouldn't impact performance much, but when I closed them random freezes when clicking every link went away...
Chromium is an excellent project but just sometimes slow to adopt certain features.
I love chrome and chromium browsers, I hardly have any issues with them.
Unlike garbage FF and unreliable Safari