Before 3.0, Android application development meant either using the SDK - which is a Java toolchain - or the NDK - which is a C/C++ toolchain based on the gcc compiler. The 3.0 version added a third option, RenderScript. RenderScript was positioned as an auxiliary toolchain for special tasks like image manipulation operations. In this post I will investigate whether it makes sense to use RenderScript for more mainstream coding problems.
If you search the web for RenderScript, you won't get too many hits.
This is due to the fact that RenderScript is really just the Google
name for the technology which is based on two powerful software
packages: the clang compiler
and the LLVM "virtual machine".
Clang is a C/C++ front-end compiler and is a strong challenger to
gcc. RenderScript code is processed by clang and is turned into LLVM
bytecode. LLVM is not a virtual machine in a strong sense as it does
not "execute" this bytecode. Rather, it provides a second
compilation step when it turns the LLVM bytecode into machine code
of the target processor.
Much like Android's
new runtime, the ART, LLVM is an Ahead-of-Time compiler. The
second compilation step either happens on the developer's machine or
directly on the device. The first option means that the Clang-LLVM
toolchain generates code for 3 processor families: ARM, MIPS and
Intel so your APK file already contains native code generated from
RenderScript code for these processors and no further compilation is
needed on the device. RenderScript code may run on graphical
co-processors and other DSPs, however. In this case the on-device
LLVM compiler accesses the LLVM bytecode which is also packaged into
the APK file and may generate code for these specialized processors
at install time.
So if you write RenderScript instead of native implementation
with the traditional NDK toolchain, you get the performance of the
native code, support of many processor architectures including more
exotic GPUs and DSPs without any hassles, get a simpler integration
with the Java code and a much smoother integration with the Eclipse
RenderScript appeared in Android 3.0 and supporting Java packages
reside under the android.renderscript hierarchy. This is called
native RenderScript. Google, however, backported the feature to
Android 2.2 (and higher) and this backported version is now the
recommended way. Instead of being part of the platform, RenderScript
support now resides in a support library and is under the
android.support.v8.renderscript package hierarchy. Functionality of
android.renderscript and android.support.v8.renderscript are largely
Even though the RenderScript runtime is general-purpose, Google
positions the technology as a solution for specific tasks. The
RenderScript tutorial, for example, concentrates mainly on the
filtering runtime that executes a RenderScript function - so called
"kernel" - on a large number of data items. This assumes a certain
class of algorithm, i.e. when the output of the algorithm depends
solely on the input and not on some intermediate result of the
computation. Simple convolution filters (e.g. the 2D filters used
widely for image filtering) are such algorithms and therefore they
are very suitable for parallel execution on multiple CPU cores. We
will see, however, that RenderScript can be exploited to speed up
algorithms that do not fit into this computation model.
In the next post I will present our benchmark program.