Inhoud
Uit de slechtste score, 32-bit Android 5.0, blijkt dat de Java-code 296% langzamer liep dan C, oftewel 4 keer langzamer. Onthoud nogmaals dat de absolute snelheid hier niet belangrijk is, maar eerder het verschil in de tijd die nodig is om de Java-code uit te voeren in vergelijking met de C-code op hetzelfde apparaat. 32-bit Android 4.4 KitKat met zijn Dalvik JVM is een beetje sneller met 237%. Zodra de sprong naar Android 6.0 Marshmallow is gemaakt, begint alles dramatisch te verbeteren, met 64-bits Android 6.0 die het kleinste verschil tussen Java en C oplevert.
De tweede test is de priemgetaltest, waarbij proef per divisie wordt gebruikt. Zoals hierboven opgemerkt, gebruikt deze code 64-bitlang gehele getallen en zullen daarom de voorkeur geven aan 64-bits processors.
Zoals verwacht, komen de beste resultaten van Android dat op 64-bit processors draait. Voor 64-bit Android 6.0 is het snelheidsverschil erg klein, slechts 3%. Terwijl het voor 64-bit Android 5.0 38% is. Dit demonstreert de verbeteringen tussen ART op Android 5.0 en de Optimaliseren compiler gebruikt door ART in Android 6.0. Omdat Android 7.0 N nog steeds een ontwikkelings-bèta is, heb ik de resultaten niet getoond, maar het presteert over het algemeen net zo goed als Android 6.0 M, zo niet beter. De slechtere resultaten zijn voor de 32-bits versies van Android en vreemd genoeg levert 32-bits Android 6.0 de slechtste resultaten van de groep op.
De derde en laatste test voert een zware wiskundige functie uit voor een miljoen iteraties. De functie werkt zowel met gehele getallen als met rekenkundige met drijvende komma.
En hier hebben we voor het eerst een resultaat waarbij Java eigenlijk sneller draait dan C! Hier zijn twee mogelijke verklaringen voor en beide hebben te maken met optimalisatie en de Optimizingcompiler van ARM. Ten eerste, de Optimizing compiler had meer optimale code voor AArch64 kunnen produceren, met betere registertoewijzing etc., dan de C-compiler in Android Studio. Een betere compiler betekent altijd betere prestaties. Er kan ook een pad zijn door de code waarmee de Optimizingcompiler heeft berekend kan weg worden geoptimaliseerd omdat het geen invloed heeft op het eindresultaat, maar de C-compiler heeft deze optimalisatie niet opgemerkt. Ik weet dat dit soort optimalisatie een van de grote aandachtspunten was voor de Optimizingcompiler in Android 6.0. Aangezien de functie alleen maar een pure uitvinding van mijn kant is, zou er een manier kunnen zijn om de code te optimaliseren die sommige secties weglaat, maar ik heb hem niet gezien.De andere reden is dat het oproepen van deze functie, zelfs een miljoen keer, er niet voor zorgt dat de vuilnisman werkt.
Net als bij de prime-test, gebruikt deze test 64-bitlang gehele getallen, dat is waarom de volgende beste score van 64-bit Android 5.0 komt. Dan komt 32-bit Android 6.0, gevolgd door 32-bit Android 5.0 en ten slotte 32-bit Android 4.4.
Afronden
Algehele C is sneller dan Java, maar de kloof tussen de twee is drastisch verkleind met de release van 64-bit Android 6.0 Marshmallow. Natuurlijk is de beslissing om Java of C te gebruiken niet zwart-wit. Hoewel C enkele voordelen heeft, zijn alle Android UI, alle Android-services en alle Android API's ontworpen om vanuit Java te worden aangeroepen. C kan echt alleen worden gebruikt als u een leeg OpenGL-canvas wilt en u op dat canvas wilt tekenen zonder Android-API's te gebruiken.
Als uw app echter zwaar moet worden getild, kunnen deze onderdelen worden overgezet naar C en ziet u mogelijk een snelheidsverbetering, echter niet zoveel als u ooit had kunnen zien.
