ART vs. NDK vs. GPU acceleration: A study of performance of image processing algorithms on Android

Andreas Palsson
School of Computer Science and Communication, KTH
KTH, 2017


   title={ART vs. NDK vs. GPU acceleration: A study of performance of image processing algorithms on Android},

   author={P{AA}LSSON, ANDREAS},



Download Download (PDF)   View View   Source Source   



The Android ecosystem contains three major platforms for execution suitable for different purposes. Android applications are normally written in the Java programming language, but computationally intensive parts of Android applications can be sped up by choosing to use a native language or by utilising the parallel architecture found in graphics processing units (GPUs). The experiments conducted in this thesis measure the performance benefits by switching from Java to C++ or RenderScript, Google’s GPU acceleration framework. The experiments consist of often-done tasks in image processing. For some of these tasks, optimized libraries and implementations already exist. The performance of the implementations provided by third parties are compared to our own. Our results show that for advanced image processing on large images, the benefits are large enough to warrant C++ or RenderScript usage instead of Java in modern smartphones. However, if the image processing is conducted on very small images (e.g. thumbnails) or the image processing task contains few calculations, moving to a native language or RenderScript is not worth the added development time and static complexity. RenderScript is the best choice if the GPU vendors provide an optimized implementation of the processing task. If there is no such implementation provided, both C++ and RenderScript are viable choices. If full precision is required in the floating point arithmetic, a C++ implementation is the recommended. If it is possible to achieve the desired effect without compliance with IEEE Floating Point Arithmetic standard, RenderScript provides better run time performance.
No votes yet.
Please wait...

* * *

* * *

HGPU group © 2010-2021 hgpu.org

All rights belong to the respective authors

Contact us: