Multi-Core Architectures and Programming

Android Programming Models

C. Kugler und E. Sert16.05.2013

Gliederung

C. Kugler, E. Sert 16.05.2013 3

Gliederung

● Motivation

● Android SDK ● Allgemeines

● Homogene Parallelisierung

● Android NDK● Allgemeines

● Homogene Parallelisierung

● SDK & NDK – heterogene Parallelisierung

● Android Renderscript

● OpenCL (Außer Konkurrenz)

● Quellen

Motivation

C. Kugler, E. Sert 16.05.2013 5

Motivation

● Anwendungsdomäne von Smartphones expandiert stetig

● Bildbearbeitung, Augmented Reality, rechenintensive Spiele … auf dem Smartphone

● Erfordert Berechnungen auf großen Datenmengen

– Parallelität in hohem Maße erwünscht

● Verschiedene Programmiermodelle (PM) sind möglich

● Android SDK (Java), Android NDK (C/C++), Renderscript (C99)

● Unterschiede im Programmierkomfort, Performance, Portabilität und Sicherheit

● Mobile Systeme sind MPSoC's mit beschränkten Ressourcen

→ optimale PM soll alle verfügbaren Ressourcen bestmöglich ausnutzen

Android – SDK

C. Kugler, E. Sert 16.05.2013 7

Android SDK – Allgemeines

● Komplettes Java-Framework für Applications (nicht mit J2SE kompatibel)

● Grundlegende Aspekte:

● Große Developer-Community (Support, ausführliche API)

● Portabilität erfordert nur Verfügbarkeit der Dalvik-VM auf der Hardware Plattform („Write once, run anywhere“)

● Type Safety → Sicherheit auf Sprachebene gegeben (jedoch Reverse Engineering einfach mit Decompiler wegen Metainformationen)

● Gründe für Performance-Schwächen

– Hoher Abstraktionsgrad

→ Optimierung durch Entwickler kaum möglich (kein SIMD)– Just-In-Time Kompilierung

– Laufzeit der Garbage-Collection

C. Kugler, E. Sert 16.05.2013 8

Android SDK – homogene Parallelität

● Homogene Parallelität: Ausnutzen von verfügbaren Cores der CPU

● Mechanismen zur homogenen Parallelisierung:

● Java Threads/Thread-Pool

– Werkzeug zur Parallelisierung für Entwickler

– Java ME vs. Android SDK: SDK besitzt spezielle Widgets und Bausteine (siehe Activities und Intents) → Entwicklung wird erleichtert

C. Kugler, E. Sert 16.05.2013 9

Android SDK – Beispiel

Thread-Erzeugung:

Synchronisation:

Android – NDK

C. Kugler, E. Sert 16.05.2013 11

Android NDK – Allgemeines

● Ermöglicht hardwarenahe Programmierung mit C/C++

● C++ Binaries werden in SDK-Anwendung mit Hilfe von JNI-Schnittstelle eingebunden

● Bionic-Lib als Untermenge des Funktionsumfangs von LibC

● Grundlegende Aspekte:

● Verwertung von Legacy-Software ohne Portierung auf neue Quell-Sprache

● Portierung von Anwendungen auf breites Hardwarespektrum erschwert

→ Einhaltung der ABI des Compilers nötig

● Keine Sicherheit auf Sprachebene gegeben → anfällig für Buffer-Overflows

● Gründe für Performance-Stärken:

– HW-nahe Programmierung → Viele Optimierungsoptionen für Entwickler

– Einbindung von Inline-Assembler– Quellcode wird in Maschinencode übersetzt → kein Interpreter nötig

C. Kugler, E. Sert 16.05.2013 12

Android NDK – homogene Parallelität

● Mechanismen zur homogenen Parallelisierung:

● Bionic-Lib bringt Implementierung von Pthreads mit (keine C++11-Threads)

– Werkzeug zur Parallelisierung für Entwickler

– Benutzung fast identisch zur LibC-Implementierung,da einige POSIX Besonderheiten wie C++ exceptions und wide chars fehlen

● Zusätzlich: Erzeugen neuer Prozesse mittels fork() möglich

– Android setzt auf Linux auf → fork() und exec() sind implementiert

– Von der Benutzung wird abgeraten → erzeugte Prozesse könnten theoretisch jederzeit abgeräumt werden

● Weiterhin Zugriff auf alle Parallelisierungs-Mechanismen des SDK

C. Kugler, E. Sert 16.05.2013 13

Android NDK – Beispiel

Thread-Erzeugung:

Synchronisation:

C. Kugler, E. Sert 16.05.2013 14

SDK & NDK – heterogene Parallelität

● Heterogene Parallelität: Ausnutzen von verfügbaren, „heterogenen“ Recheneinheiten (z.B. GPU, DSP, ...)

● Mechanismen zur heterogenen Parallelisierung:

● Kein GPGPU möglich

● OpenGL ES 2.0 – Unterstützung

– Benutzung der Grafikkarte zur ausschließlichen Berechnung des Grafik-Anteils der Anwendung

– Programmierung der Grafikkarte über Shader möglich

– Limitierungen: z.B. nur single-precision floats

● Keine weitere Unterstützung von heterogener Parallelität

Renderscript

C. Kugler, E. Sert 16.05.2013 16

Renderscript – Allgemeines

● Programmierung basiert auf C99-Standard

● Bringt diverse Funktionalität in eigenen API's mit

● Graphics-API, inzwischen als veraltet eingestuft

– Ermöglicht einfache Nutzung von Meshes, Texturen, Surfaces ...

● Compute-API, ermöglicht GPC auf heterogenen Kernen

– Ausführung von Kernel-Funktionen durch Worker-Threads (vgl. OpenCL)

● RS-Scripte werden in SDK-Anwendungen eingebettet (vgl. NDK)

● Script wird von LLVM (Frontend-Compiler) zunächst in Zwischencode übersetzt

→ gewährleistet Portbierbarkeit wegen Hardwareunabhängigkeit

● Generierung von Reflection-Classes als Schicht zwischen RS und SDK

● RS-Script muss explizit aus SDK-Teil der Anwendung aufgerufen werden

– Zugriff auf Variablen des Skripts über auto-generierte GET'er / SET'er

C. Kugler, E. Sert 16.05.2013 17

Renderscript – Parallelisierung

● Homogene und heterogene Parallelisierung gleichermaßen automatisch, transparent abgedeckt

● Implizite Nutzung aller phys. Recheneinheiten (bisher CPU, GPU)

● Zuteilung von auszuführendem Code zu Recheneinheiten wird zur Übersetzungszeit bestimmt (Entscheidung des Backend-Compilers)

● Der Entwickler hat keinen Einfluss auf die Zuteilung

Fig.1 - [Bench]

C. Kugler, E. Sert 16.05.2013 18

Renderscript – Details(1)

● root-Funktion als Einstiegspunkt

● Default: void root( const uchar4* v_in, uchar4* v_out){ … }

– v_in, v_out: Allocations● Custom: __attribute__((kernel)) root(iunt32_t x, uint32 y){ … }

● wird mehrmals aufgerufen

● Sprung in root-Funktion über „forEach_root()“ / „rsForEach()“ ● Aufrufe der root-Funktion werden auf vorhandene Recheneinheiten verteilt

– Performance skaliert mit Anzahl der Prozessoren

● Nicht alle Recheneinheiten sind gleichermaßen mächtig

– Ist eine Recheneinheit nicht fähig den Code auszuführen wird er automatisch auf der CPU ausgeführt (Bsp. Keine Doubles auf GPU)

C. Kugler, E. Sert 16.05.2013 19

Renderscript – Beispiel(1)

C. Kugler, E. Sert 16.05.2013 20

Renderscript – Beispiel(1)

C. Kugler, E. Sert 16.05.2013 21

Renderscript – Beispiel(1)

root-Funktion

C. Kugler, E. Sert 16.05.2013 22

Renderscript – Beispiel(1)

Allocations

root-Funktion

C. Kugler, E. Sert 16.05.2013 23

Renderscript – Beispiel(1)

Allocations

root-Funktion

Ergebnis schreiben

C. Kugler, E. Sert 16.05.2013 24

Renderscript – Beispiel(2) SDK-init

C. Kugler, E. Sert 16.05.2013 25

Renderscript – Beispiel(2) SDK-init

C. Kugler, E. Sert 16.05.2013 26

Renderscript – Beispiel(2) SDK-init

C. Kugler, E. Sert 16.05.2013 27

Renderscript – Beispiel(2) SDK-init

Buffer allokieren

C. Kugler, E. Sert 16.05.2013 28

Renderscript – Beispiel(2) SDK-init

Zugriff auf „reflected Class“

C. Kugler, E. Sert 16.05.2013 29

Renderscript – Beispiel(2) SDK-init

Zugriff auf Datenstrukturen im Skript

C. Kugler, E. Sert 16.05.2013 30

Renderscript – Beispiel(2) SDK-init

Skript ausführen!

C. Kugler, E. Sert 16.05.2013 31

Renderscript – Ergebnis

Vorher: Nachher:

Blur-Filter

C. Kugler, E. Sert 16.05.2013 32

Renderscript – Details(2)

● Allocations – Buffer auf dem ein Kernel arbeiten kann:

● vergleichbar mit Arrays (Speicher ist getypt)

● Speicherbereiche die im SDK allokiert werden

● Werden über Pointer an Funktionen (Kernel) des RS-Scripts übergeben

● Workaround: Dummy-Allocations

→ um Aufrufanzahl von Daten unabhängig zu machen

→ Input-Daten müssen dann über RS-globale Variablen übergeben werden (gleiches für Output-Daten, falls Größe nicht passt)

# Aufrufe (root ) ≡ # Elemente (AllocationIN)

# Elemente (AllocationIN) ⇒ # Elemente(AllocationOUT)

C. Kugler, E. Sert 16.05.2013 33

Filterscript & Script Intrinsics

● Seit Android 4.2 (API Level 17) verfügbar

● Filterscript:

● RS-Subset mit Fokus auf Image-Processing

● Verwendet Untermenge der RS-API um eine größere Kompatibilität und Optimierung zu erreichen hinsichtlich auf CPUs, GPUs und DSPs

● Keine Pointer → nur Gather-Read möglich, kein Scatter-Write

– Erzwingt cache-freundlichere Programmierung auf Kosten von Flexibilität

● Script Intrinsics:

● Erweiterung der RS API um diverse, hoch-optimierte Filterungs-Funktionen

● Entwickler muss Funktionen nicht mehr selbst schreiben

Vergleich

C. Kugler, E. Sert 16.05.2013 35

Vergleich

● SDK

● hoher Programmierkomfort

● sehr gute Portabilität

● Abzüge in der Performance

● NDK

● weniger gute Portabilität

● aber viel bessere Performance möglich (liegt in Verantworung des Entwicklers)

● Renderscript:

● etwas komplizierte Programmierung (memory allocation)

● Portabilität ähnlich gut wie bei SDK

● sehr gute Performance (gleichmäßige Ressourcenausnutzung)

OpenCL

C. Kugler, E. Sert 16.05.2013 37

OpenCL – (Außer Konkurrenz)

● Motivation wie bei Renderscript: OpenGL ES ist nur für 3D Rendering auf mobilen Plattformen verwendbar

● General-Purpose-Computing nicht möglich, da kein/e:

– Scatter-Write,

– Threads mit dynamischer Speicherzuteilung (Blöcke)

● Kein offizieller Support von OpenCL auf Android-Devices

→ Renderscript an Stelle von OpenCL

● Inoffizielle Treiber existieren für wenige Hardware-Architekturen:

● Exynos 5 / ARM Mali - in Google Nexus 10

● Snapdragon S4 Pro / Adreno - in Sony Xperia ZR

● … ?

Quellen

C. Kugler, E. Sert 16.05.2013 39

Quellen

● Xi Quian, Guangyu Zhu, and Xiao-Feng Li "Comparison and Analysis of the Three Programming

Models in Google Android"

● Guohui Wang, et al. "ACCELERATING COMPUTER VISION ALGORITHMS USING OPENCL ON

MOBILE GPU - A CASE STUDY"

● http://developer.android.com/guide/topics/renderscript/compute.html

● ??? „Code Generation for Embedded Heterogeneous Architectures on Android“

● http://developer.android.com/reference/android/renderscript/package-summary.html

● [Bench] http://android-developers.blogspot.de/2013/01/evolution-of-renderscript-performance.html

● http://developer.android.com/guide/components/Prozesses-and-threads.html

● https://computing.llnl.gov/tutorials/pthreads/

● http://www.karbacher.org/android/unterschiede-von-android-zu-java-me-j2me/

● https://www2.cs.fau.de/teaching/WS2012/UE1/uebungen/ueb06.pdf

Anhang

C. Kugler, E. Sert 16.05.2013 41

Anhang – RS-Portabilität

LLVM backend compiler

BC → MI

Zwischengespeicherte Version der Maschinen Instruktionen vorhanden → wird nur bei Änderungen erneuert

C. Kugler, E. Sert 16.05.2013 42

Anhang – Vergleich RE

C. Kugler, E. Sert 16.05.2013 43

Adroid Emulator - Linux

● Android SDK benötigt (download unter: http://developer.android.com/sdk/index.html)

● Starte $SDK/tools/android ($SDK = Pfad zum SDK)● Aktiviere im Hauptfenster Tools > Android SDK Plattform und ARM EABI v 7 a

System Image → klicke Install 3 packages

● Tools > Manage AVD → Butten new klicken Target Android X.X.X (API XX) → create AVD legt Emulator an

● Mit $SDK/platform-tools/adb push {file} /data/local/tmp können Daten auf Emulator kopiert werden

● Mit $SDK/platform-tools/adb shell, erhält man ein shell für das emulierte Gerät