Using absl containers in Chromium

[Ali Tofigh]

When measuring CPU usage of Chrome under certain common video conferencing scenarios using webrtc, we see that about 3% of CPU is spent in std::map. We would like to convert some of these std::maps to the appropriate absl containers like absl::flat_hash_map.

As an example, here is a CL where one use of std::map is replaced with absl::flat_hash_map: https://crrev.com/c/2549862

Profiling on Mac shows that the in the above case, absl::flat_hash_map uses ~65% less CPU compared to std::map.

Could we start allowing use of absl containers in Chrome's codebase?

[Michael Ershov]

Don't have anything against absl, but I'm just curious about existing flat_map and other containers in chromium.

Are they worse than the ones from absl? 

If not, we can just use them. 

If yes, we can consider redefining base::flat_map as absl::flat_map.

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/bb1cdb71-5f1f-475b-a5e1-1a7b1903968dn%40chromium.org.

Michael Ershov

Software Engineer

mie...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. 

     

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[dan...@chromium.org]

More details in here about choosing the right container: https://chromium.googlesource.com/chromium/src/+/master/base/containers/README.md#Map-and-set-selection-Usage-advice

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACs097DA03mfC-Dxa46Xt65dN_ptoMDE78MZehe9WiLiVcW6TQ%40mail.gmail.com.

[Jeremy Roman]

I think @Daniel Cheng has looked into this to some extent.

base::flat_map isn't a hash map (so it has somewhat different performance characteristics than absl::flat_hash_map, but still better than std::map for many uses).

We've talked about adopting Abseil's associative container types, and I think the largest barrier was investigation of how they perform on Chrome's supported platforms, as opposed to the Google x86_64 server environment they were designed for. (ISTR there were some x86-specific tricks in there, but that's not to say they aren't also a good choice on mobile ARM/ARM64).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAHtyhaQX-GvPrAo%3DmM-cFcbhPtRJJD08xXNCpM2_pumDgVx2gg%40mail.gmail.com.

[Daniel Cheng]

https://crbug.com/1121345 is the bug for tracking using Swisstables in Chrome.

I would like very much for this to be a thing; however, benchmarking ARM is one of the blockers here so if anyone has tips/devices/ways to help with that...

Daniel

[Ali Tofigh]

What benchmarks would you need to run on ARM devices? And do you have examples of devices that would be suitable to use? Maybe we can help dig up some devices.

[Daniel Cheng]

I think a good starting point would be https://github.com/google/hashtable-benchmarks. Unfortunately, at the moment, it doesn't appear to build, but the small patch I've attached fixes it (by commenting out the F14 tests. Do we want to investigate F14 as well? My sense is it's probably easier to stick with the absl ecosystem). You'll also want to symlink .bazelrc in the checkout root to tools/bazel.rc.

As for what ARM devices to test, I don't know much there; we should probably ask the Android/Cast (?)/CrOS teams where they'd want coverage. We'd also want to test Android-specific build configs--IIRC, most of the Android binary is much less aggressive about inlining and optimizes a lot more for size rather than speed. +Richard Townsend or +Adenilson Cavalcanti might also have some suggestions on good platforms to test.

Daniel

[Adenilson Cavalcanti]

Hey Daniel

First, let me say thanks for adding me and Richard to the discussion, I really appreciate it (sorry for the late reply, I'm on vacation and should be back to work in 2 weeks).

It is really nice to see awareness concerning ARM performance on changes that may impact the whole code base like migrating to absl::flat_hash_map.

Going back to the original question related to benchmarking: my suggestion would be to have at least 4 devices from at least 2 silicon vendors, being 2 high end devices and 2 affordable devices.

The reason for having more than a single silicon vendor is that it is possible that a given vendor has introduced micro-architecture changes. Using devices from a single vendor may skew optimization efforts, as I've observed in my own optimization work in zlib.

Another important detail to factor is that ARM chips generally have an heterogeneous architecture (i.e. big.LITTLE), so either ensure that a given benchmark is running on a specific core (e.g. a big core) or in case of affordable devices, it may have only little cores. What may be faster on bigs, may be actually slower on littles.

Performance gains may vary significantly (e.g. +/- 20%) if running on 32bit or 64bit. It seems that Chrome is migrating to be distributed to Android devices as a 64bit binary, but 32bit is still an important share of the users.

I generally use 2 pixel devices (e.g. pixel 4 and a pixel3a), another vendor higher end device (e.g. Huawei Mate 20 Pro) and 2 ARM boards running 64bbit linux (one has a A72 core and the other has a A53 core). The advantage of running linux is access to full 'perf' for profiling, while on Android there is 'simpleperf' which works fine but has some limitations.

Finally, it may be helpful to have enough data (e.g. 30 runs) and work with the median of runs to help tackle variation and plotting the data is always helpful to understand trends (e.g. for optimizing data compression speed in zlib: https://docs.google.com/spreadsheets/d/1xsWqBdAPFgC3X6AZLjvRVwSgCA2EtwdHeqUGHFtESnQ/edit?usp=sharing).

If there is anything else we could do to help, please let us know we would be glad to collaborate in efforts to improve performance on ARM devices.

Best regards

Adenilson