ARM64 orderfile and performance evaulation |
||
Issue descriptionTo better understand the implications of transitioning clank to 64 bit on android platforms we'd like to see if orderfiles tailored to the 64 bit platform make a difference. Our hypothesis is that it won't make much difference. Let's see! The gn args for the build we're interested in are: use_goma = true target_os = "android" target_cpu = "arm64" is_debug = false is_official_build = true android_64bit_browser = true The chrome performance benchmarks we'll look at are: speedometer system_health.memory_mobile system_health.top_10_mobile We'll compare a TOT build (which uses the orderfile generated from the 32 build) with an orderfile generated for the 64 build defined as above. This 64 bit orderfile should be easily generated by tweaking the build parameters locally and generating an orderfile on a local device. This does mean that the 64 bit orderfile will be done using a Pixel 2, whereas the 32 bit orderfile is from a Nexus 5. Our previous orderfile work suggests this won't cause a big difference, but it will be something to look into if the 64 bit orderfile does have a large impact on performance.
,
Jan 17
(5 days ago)
32 and 64 bit orderfiles from the same tot can be found at /google/data/rw/teams/clank-team-paris/order64/ (or the equiv x20 link). The hash on the end is the TOT where the 64 bit orderfile was generated from; the 32 bit orderfile is from the bot. I'm starting to run benchmarks locally, but if you want to get a headstart, grab the orderfile of your choice, copy it to clank/orderfile/orderfile.arm.out, touch chrome/browser/chrome_browser_main.cc (or whatever file to force a rebuild). Note that the same orderfile.arm.out is used irrespective of your target_cpu setting.
,
Jan 18
(4 days ago)
I put speedometer2 results in the google/data directory, comparing 64-bit monochrome built with the 32 and 64 bit orderfile. The results are not significantly different, 18.2 runs per minute for order32 and 18.1 for order64 with sd of 0.44 and 0.42, respectively.
,
Jan 18
(4 days ago)
Thanks Matt, I've rebuilt my APKs to include the Arm64 order files and will run some of the test again to see if there is any impact on the C++ categories.
,
Jan 18
(4 days ago)
SG. I'm pre-empted tracking down a bug on a local device, but hopefully will be able to run some more benchmarks next week if it would be helpful.
,
Yesterday
(41 hours ago)
I ran a couple of benchmarks and did see some impact of the code ordering. I was comparing the arm32/arm64 regressions between my preceeding runs and these runs (not the with/without arm64 code ordering yet) so the results might not be entirely representative, however. - Speedometer regression reduced from 7.7% regression to 6.5% regression - Speedometer 2.9 regression reduced from 5.5% regression to 4.8% regression - The native_library_proportional_resident memory regression in system_health.memory_mobile reduced from 71.5% to 45.1% - This in-turn reduced the (non-gpu) proportional_resident_set memory metric's regression from 13.6% to 10.8% Unfortunately a number of the other benchmarks I ran over the weekend failed (I would like to see the proportion of time spent in C++ for speedometer to see if that caused any of the impact or it is just noise), but the reduction in native_library_proportional_resident seems like the Arm64 specific code ordering is doing something significant.
,
Yesterday
(41 hours ago)
^ /s/Speedometer 2.9/Speedometer 2.0/
,
Yesterday
(40 hours ago)
>> - The native_library_proportional_resident memory regression in system_health.memory_mobile reduced from 71.5% to 45.1% Wow, that is nice & does seem significant.
,
Today
(18 hours ago)
|
||
►
Sign in to add a comment |
||
Comment 1 by rmcilroy@chromium.org
, Jan 16 (6 days ago)