Optimize Geekbench* Performance in ChromeOS*

An In-Depth Analysis and Impact on Benchmark Scores

Geekbench¹ is widely used for CPU benchmarking across various operating systems and platforms such as Windows*, Linux*, Android*, and macOS*. In ChromeOS*, Geekbench can run in three different environments:

• Android version in ARCVM (Android Runtime Compatibility for Virtual Machines)
• Linux version in Crostini* VM (virtual machine)²
• Linux version in Chrome

This article explores the key differences between the Android Application (APK) version and the Linux version in Chrome operating environments, and provides a detailed analysis of software stack variances, subtests, and operational flow. Benchmark scores are derived using the Chromebook* notebook featuring Intel® Core™ processors.

It also examines the technical details of the Android memory allocator and explores potential optimizations to enhance performance. Additionally, this article highlights the successful implementation of optimization for memory sharing between the Android virtual machine (VM) and the guest machine. This optimization plays a pivotal role in significantly enhancing the performance of Geekbench and various other workloads.

Factors Affecting CPU and Memory Evaluation

Geekbench is a widely used CPU benchmark for evaluating and optimizing CPU and memory performance using workloads that include data compression, image processing, machine learning, and physics simulation. Performance on these workloads is important for a wide variety of applications including web browsers, image editors, and developer tools.

Although the same subtests are run as part of the Geekbench benchmark, critical characteristics of the operating environments determine the subtest levels and final scores. These characteristics include but are not limited to CPU runtime, instructions per clock, branch miss rate, memory latency, and cache miss rates. Understanding these operating environment factors is vital to understanding the Geekbench scoring mechanism for making meaningful comparisons.

Differences in Operating Environments

Chrome and Android operating environments differ in several key ways, with the primary distinction being memory allocation mechanisms and software stacks. Figure 1 shows a high-level overview of the differences in memory allocation flow between Android, which uses Bionic libc, and Chrome, which uses the GNU C library. This contrast is one of the key differences in these operating environments.

Figure 1. Chrome and Linux GNU C Library compared to Android Bionic libc (memory allocation).

GNU C Library for Linux

• The GNU C Library³ provides the core libraries for the GNU system, GNU/Linux systems, and many other systems that use Linux as the kernel, including Chrome.
• The GNU C library is described in the ANSI, C99, and C11 standards. It includes macros, symbols, and function implementations, such as print() and malloc().
• The GNU libc is a POSIX standard library and serves as the userland glue for system calls, such as open() and read(). Specifically, GNU C library does not implement system calls; the kernel does that. However, GNU C library provides the userland interface to services offered by the kernel so that user applications can use a system call just like an ordinary function.
• The GNU C Library uses malloc for dynamic memory allocation.

Bionic C Library (libc) for Android

• Bionic C library (libc)⁴ is a C library specifically created for Android mobile and embedded environments, providing essential C standard library functions. It prioritizes performance and memory efficiency for mobile applications.
• Bionic features a custom implementation that is optimized for embedded systems.
• Known for its small size and fast code paths, it provides very fast, custom pthread implementations.
• For dynamic memory allocation, Android uses jemalloc
• Bionic C library is not compatible with GNU C library.

Comparative Analysis: Memory Allocation in Chrome and Android Environments

Geekbench Subtest Scores

See table 1 for a detailed comparison of benchmark scores obtained from the Linux version of Geekbench run in the ChromeOS shell, Crostini shell, and the Android version of Geekbench run in ARCVM on the Chromebook* platform featuring Intel® Core™ Ultra Processors.

Table 1. Geekbench Score Comparison between Different Operating Environments

Further analysis identifies a notable disparity in the performance of subtests (HTML5, SQLite*, Clang*) that are influenced by memory allocation and access. Table 2 shows a detailed comparison of subtest scores.

Table 2. Geekbench Subtest Score Comparison between Different Operating Environments

As shown in figure 2, the memory logs confirm that the Linux version of Geekbench has a maximum allocation of memory, whereas the Android version is not able to get a complete allocation.
 

Figure 2. Memory use

The Android version of Geekbench uses significantly less memory, with only 0.45 GB compared to the 1.3 GB used by the Linux version, indicating a lower memory allocation for Android. The Linux version employs the GNU C library (glibc/libm) and standard malloc for dynamic memory allocation, while the Android version relies on Bionic C library (libc) and jemalloc.

The jemalloc Memory Allocator

The jemalloc⁵ memory allocator is a general-purpose malloc implementation that emphasizes fragmentation avoidance and scalable concurrency support. Using jemalloc reduces performance but also lessens memory fragmentation. Google must decide the extent of acceptable performance degradation.

The jemalloc memory allocator offers several adjustable parameters, which are often conservatively set by default and may not be ideal for numerous typical workloads. Properly calibrating jemalloc for a particular application or workload can commonly enhance system-level performance by a small percentage or allow for beneficial trade-offs. To achieve optimal tuning, it is necessary to acquire jeprof files within the Android operating system. However, ChromeOS currently lacks the infrastructure for deploying Android OS images.

Memory Allocation Dynamics

• Android operates within a virtual machine environment, with memory management handled by crosvm, which uses a ballooning policy.
• The ballooning policy is informed by the Low Memory Killer Daemon (LMKD) within Android to guide memory allocation.
• In contrast, the Linux version of Geekbench runs directly, adhering to a standard memory allocation policy that grants requested memory without modification.

User Interface and Command-Line Application Resource Use

• The command-line interface (CLI) version of Geekbench for Linux is more memory-efficient compared to the Android APK, which includes a graphical user interface (GUI).
• The CLI version does not engage graphics modules, avoiding the additional overhead associated with the Android graphics pipeline.
• The Java UI threads in the APK introduce further overhead. See figure 3.

Benchmark Runtime Comparison

Geekbench running on Linux via the CLI completes in 175 seconds, whereas the Geekbench APK version takes 200 seconds to finish.

Java Native Interface (JNI) Calls

JNI calls are generally slower. See figure 3.

Figure 3. JNI calls

Given the factors causing the bottleneck in Geekbench scores, strategies focus on bridging the gap between the built-in Android version and the Android version running in a virtual machine (VM) deployment.

Optimization Strategy 1: Fine-Tune jemalloc Parameters

Continued investigation into fine-tuning jemalloc parameters yields substantial performance enhancements. Our experiments, which involve running Geekbench workloads with modified jemalloc settings, indicate notable improvements in performance. The jemalloc dirty_decay_ms configuration parameter, in particular, had a pronounced impact on the performance of the malloc-intensive Geekbench multicore (MC) workload.

Table 3 details insights into the performance trends of the Geekbench MC scores under various dirty_decay_ms settings in a virtual machine environment.

Table 3. Geekbench Score Comparison with dirty_decay_ms Parameter Settings

The following elements contribute to the observed performance improvements:

• An approximate 28% decrease in CPU cycles per second
• A decrease in the number of vm_exits caused by EPT_VIOLATION
• A reduction in the overhead associated with memory ballooning

Moreover, configuring the narenas parameter to align with the available number of CPUs (rather than using the fixed value of 12) has resulted in further gains. Geekbench MC scores on Chromebook platforms based on Intel® Core™ i3 N processors experienced an additional increase of 2% to 3%.

Strategy 2: Responsive Ballooning (VM Memory Management Service)

Implementing the responsive ballooning feature successfully eliminates the overhead traditionally associated with limited cache memory ballooning. This leads to performance gains of approximately 8% to 10%.

This significant enhancement refines the existing cache ballooning policy of ARCVM by restructuring it to incorporate a broader range of metrics. The new design focuses on managing memory distribution more effectively between the guest (Android VM) and the host (ChromeOS). This ensures a more dynamic and efficient allocation of resources, responding adeptly to the needs of both environments.

Results from Fine-Tuning and Responsive Ballooning

Optimization Strategy 1: Fine-Tune jemalloc Parameters

Modifying the jemalloc dirty_decay_ms parameter to a 30-second interval resulted in performance gains across a diverse set of workloads on multiple ChromeOS platforms. The following table details the observed performance gains.

Table 4. Performance results with optimal (30x) dirty_decay_ms value

Strategy 2: Responsive Ballooning (VM Memory Management Service)

Tables 5 through 8 display a comparative analysis of Geekbench 5.4.5 scores between Android versions (performed within a VM environment) and their Linux counterparts across different platforms. With the introduction of the responsive ballooning feature, the performance disparity between the Android and Linux versions of Geekbench notably narrows to less than 10%.

Table 5. Geekbench Scores Using Chromebooks Based on 11th Generation Intel® Core™ i7 Processors

Table 6. Geekbench Scores Using Chromebooks Based on Intel Core i3 N Processors

Table 7. Geekbench Scores Using Chromebooks based on 12th Generation Intel Core i7 Processors

Table 8. GeekBench Scores Using Chromebooks based on 13th Generation Intel Core i7 Processors

Conclusion and Next Steps

The analysis of Geekbench workloads and their respective operating environments reveals distinct differences between the built-in Linux version and the Android version running within a VM environment. These differences are responsible for the variations in benchmark scores. Although the optimizations are effective in reducing this gap, they are not sufficient to fully bridge it. Certain inherent constraints within the VM software stack are irremovable, which prevents the complete equalization of performance between the two versions. However, these insights pave the way for future developments, and ongoing research and innovation hold the potential for further enhancements, leading to even more robust performance improvements in virtualized environments.

Test Configuration

Platform: Nissa Chromebook notebook

Software: Google ChromeOS CPFE R124-15810.0.0

Hardware: Intel Core i3 N305 processor, 8 GB RAM

References

1. Geekbench Website
2. Run Custom Containers under ChromeOS
3. The GNU C Library
4. Bionic: Android's C Library, Math Library, and Dynamic Linker
5. Jemalloc: Memory Allocator