ARM64 Performance Tested: Can a Mobile Processor Handle Everyday Linux Development?

In the last few years, mobile phone SoCs have shown significant performance improvements, featuring multiple high-performance cores, substantial memory bandwidth, and robust integer computing capabilities. However, for developers, the practical value of these enhancements lies in their ability to handle real-world Linux development tasks.

Developers want to know how well a complete Linux development toolchain performs within an ARM64 environment, including compile times, multi-core utilization, and overall development experience. To investigate these questions, I utilized my old OnePlus Ace5 mobile phone, installed NimoteCode, and conducted a series of tests involving CoreMark, SQLite source code compilation, and multi-file parallel builds.

My goal was to determine whether Android phones with local Linux installations can serve as practical development tools and whether their performance meets standard expectations. The test environment utilized NimoteCode's Linux deployment, running Ubuntu 24.04.4 LTS in an ARM64 container. The hardware specifications included an 8-core CPU with a configuration of 5 Cortex-A720 + 1 Cortex-A725 + 2 Cortex-A520 high-performance cores, 10 GiB of memory, and a GCC 13.3.0 compiler.

One important note is that the test environment had limitations, such as restricted CPU frequency and system hardware information visibility, which made it challenging to accurately measure CPU frequencies and scheduling behavior. Despite these limitations, the test results provided valuable insights into the ARM64 processor's capabilities.

CoreMark, a benchmark tool measuring workloads like integer operations and matrix calculations, yielded a single-core score of approximately 23,400 and an 8-thread total score of around 144,200. Notably, the multi-core performance showed an impressive 6.15x improvement, albeit not the ideal 8x improvement expected. This finding highlights the processor's ability to effectively utilize multiple cores, even though the actual utilization may be affected by factors such as frequency allocation, memory access, and power consumption.

However, it's essential to recognize that CoreMark represents a specific computational workload and does not directly correlate with the performance of real-world development tools like GCC, Git, or Python. Therefore, to gain a more comprehensive understanding, I proceeded with compiling the amalgamation source code of SQLite 3.54.1, a mature embedded database project.

The source code, containing about 271,131 lines of C code, offered a practical test of the compiler's capabilities, including lexical analysis, syntax analysis, optimization, and code generation. Compiling the SQLite code with GCC's -O0 and -O2 optimization levels yielded interesting results. With -O0 optimization, the compilation took roughly 7.6 seconds, while -O2 optimization increased the time to approximately 34-35 seconds.

Interestingly, the -O2 level compilation was about 4.5 times slower than -O0, despite the increased complexity of GCC's optimization process. This indicates that while optimization may improve code efficiency, it also requires more computational resources and time.