I am using Marmalde and C/C++ to write an game for android.
Now I eant to write some important parts in assembler to improve the performance.
But I am wondering me whether this app could run on the most android devices? (about 90%)
Because in general assembler code depends on the processor and different android phones may have different processors, for example Intel or ARM, so I would have to write these parts in different assembler languages for every different processor!?
Yes, of course you will have to write the assembly code for every processor ABI.
The Android NDK has specific support for different ABIs.
Keep in mind that, while there are currently only three processor families supported (Intel x86/64, ARM and MIPS) you have to target all the different ABIs not the processors families themselves.
You can drop MIPS devices safely, they are very rare.
Intel devices are mostly tablet, but there are some phone too.
The vast majority of devices out there is ARM.
If you look at an official optimization guide from ARM v8 or at a very useful optimization guide for Intel you can see that it actually will take some time to write good assembly code, it's not just about making something work (which you should already be able to do easily).
Hint
Write first the critical parts in C++, then look at the disassembly and see if you can do better or if you can recognize some sub-optimal patterns.
Only then rewrite the code in assembly.
Also before doing such micro-optimizations, try to use better data structures, better algorithms and better resource handling.
Related
Well there are many tutorials and post about this, but I am not getting exactly how to deal with libOpenCL.so file. Many vendors does not include it inside phone, but my app needs to support maximum available phones today, so do I need to get compatible libOpenCL.so file for each of them?
OpenCL is not officially supported by Android Open Source Project
See: Why did Google choose RenderScript instead of OpenCL
However it appears that Device Manufacturers are including support by adding in the driver.
See: Does Android support OpenCL?
Realize that OpenCL is at a similar layer in the hardware stack as the graphics driver and any particular implementation will depend on the manufacturer and would be specific to that device. You can't just take a libOpenCL.so from one ARM64 device and expect to work for another due to system-on-a-chip specific customizations (number of cores, DSPs, GPUs etc.)
My recommendation from: C++, OpenCV and "what" for cross-platform GPU programing
If you want maximum support - stick to C/C++ code.
If you need OpenCL to make your app performant even with parallelized code, your option is to check if the library is there and warn the user about the lack of support. Ideally then fall back to the parallelized code on those devices without OpenCL.
Until Google makes OpenCL part of the Android Compatibility Definition Document and requires some metadata property, only by the app checking on the device can the app know that OpenCL is even available.
Adding to the answer of #Morrison Chang:
You can not rely on all version of OpenCL in all devices to have everything supported. So I would do a dinamic library loading, and query at runtime for the OpenCL methods are available.
Regarding the library with OpenCL support, sometimes is not even called like that. For example libGLESmali.so has OpenCL symbols and can be used directly.
Is Way To Run Machine Code Instead Android OS In Android Devices ?
I Want Remove Android Os And Work With Cpu And Other Devices Directly .
What Compiler I Can Use ?
MASM is an x86 assembler, so it would not be suitable for most Android devices as the vast majority use ARM-based processors.
That said, Android phones are computers just like any other and can be programmed in assembly. The first thing you'll need to do is select a device running a well documented CPU and chipset.
Since you'll be removing Android and plan on programming in assembly you'll need to write your own routines for nearly everything. An understanding of the CPU, power management and some form of I/O (you can avoid having to write complex display code if you plan to interface with the phone through serial communication, for example).
Unfortunately, much of the information required for successfully writing your own OS for an Android device is unavailable so you'll need some hardware analysis tools to assist in reverse engineering some of this information. A logic analyzer may be useful in sniffing some of the protocols used between chips, although much of modern phones is done on a single SoC, so you'll need to experiment heavily and compile information from a wide variety of online sources.
Aside from that, it's smooth sailing. Programming an OS in assembly for Android is pretty much the same as programming an OS in assembly for any other computer and you'll find it to be rather familiar territory.
So like in Linux on Intel processor, we have a large amount of hardware performance counters to access. Like previously, using a user-space software called perfmon2, I could get values of cache miss rate, CPU stalling cycles due to some reason(e.g,. L1 cache miss) and etc.
My question is , do we have those stuff in Android? Since it's based on ARM, I do not think we have as strong performance monitor counter support as we have in x86, right?
ARM11 and Cortex-A/R do have hardware performance counters. You can check that on the official ARM website on this page: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka4237.html
Since Android is also running on top of Linux, you can access performance counters through user-space software via the "Perf Events" subsystem. However, you will need to write native C code, which includes "perf_event.h" and build it using the Android NDK. Before you start writing code, I suggest you take a look at this project: platform/external/linux-tools-perf (https://android.googlesource.com/platform/external/linux-tools-perf/), which may be exactly what you are looking for. I don't know about any alternatives which allow doing this directly from Java Code.
In addition to Benny's answer, I'll add the following:
The linux-tools-perf project is integrated with the AOSP (I'm using 4.2). It is under $AOSP/external/linux-tools-perf. The ./linux-tools-perf/Documentation contains a lot of info on how to run everything. The perf tool is built in $PRODUCT_OUT/system/bin/perf as part of the AOSP but not packaged; you need to explicitly push it to the target.
Check the Android (linux) kernel to confirm it supports PM: PERF_EVENTS. Google how to get .config but easiest is running "extract-ikconfig zImage".
One needs to have root access on the target and then run something like "./perf stat -- testprog1" to see results. There are a lot of arguments to the command to record/retrieve different PM counters.
Remember most ARM implementations have multiple cores and A LOT of pipelining. Cortex-A9 has out-of-order execution. So the numbers can be a little freaky - almost meaningless sometimes.
I use the ARM PMCCNTR register, the ARM PM Cycle Counter, occasionally to test code performance. PMUSERENR.EN and PMINTENCLR.C must be set at PL1+ level and then PMCCNTR can be managed at PL0 level. See the ARM ARM for what all this means and the perf subsystem for example usage!
Note: All the shell vars are set up in $AOSP/build/envsetup.sh
I think you can try to use ARM® HWCPipe Exporter.
ARM® HWCPipe Exporter is a Prometheus exporter written in Java and C++ that retrieves metrics from Android devices running on ARM® Hardware components and exports them to the Prometheus monitoring system.
Disclaimer: I am the author of ARM HWCPipe Exporter.
I am developing an Android game, which I will upload to the market. I am using the NDK; the majority of the game code is C++.
Should I worry about supporting x86 devices? Are there actually any out there?
Currently I am building for ARMv6 only; building for both ARMv6 and v7 increases the APK size without making it any faster (it's already fast enough). It would be nice if I only needed to build for a single architecture.
If you can do it without too much hassle, I would do it.
Not because there are tons of Android/x86 devices, but simply because supporting multiple architectures is a fantastic way to shake out bugs that you might otherwise never encounter (or that would lie dormant until something changes on the system two years from now, and suddenly your app doesn't work anymore). It will make you a better programmer.
Also, I'm surprised that building for armv7 doesn't confer any advantage. Do you mean that you're already framerate-capped running the armv6 build on an armv7 device? If so, building armv7 may still allow your code to run faster, which typically saves energy even if it doesn't increase "performance". Less energy = people use your app longer.
Now, all that said, I don't know the Android toolkit, so I don't know how much hassle is actually involved with supporting multiple arches. If it's a major hassle, then by all means stick to armv6; it's a good baseline for "most" devices out there.
Not a bits, bytes, algorithm and syntax question... but a technology development and business one. Hope that's ok.
At CES 2011, mips.com unveiled new MIPS-processor based smart phones running Android. By what I've read, it sounds like these either might be Chinese-market only (which, lets face it... is huge) or part of a big push by MIPS to elbow into ARM's territory.
Here are problems I see:
- Google only provide first-class support for ARM. Their SDKs are ARM-only. Does anyone know if they have plans to adopt MIPS?
- The Android Market is ARM-only, as far as I can tell. It looks like companies like Velocity Micro (and their little MIPS-based Cruz tablet) have their own "Cruz Market". I think that's awful. Is the Android Market going to be the one-stop shop for Android, or are things fragmenting even more?
- The JNI breaks the processor-independence of the VM. Can multiple processor-specific JNI libraries be packaged into a single app? MIPS binaries aren't exactly small.
Does anyone out there have a crystal ball on these things? Let the assumption be: MIPS won't just go away.
TL;DR: Anyone know WTF is going on with MIPS?
Their SDKs are ARM-only.
The Android SDK is processor-agnostic, outside of emulator images.
Does anyone know if they have plans to adopt MIPS?
The verb "adopt" is too nebulous for anyone to answer this question.
The Android Market is ARM-only, as far as I can tell.
I am not aware of a non-ARM device that meets the Android Market compatibility requirements. This is not a chipset thing, it's a compatibility thing. For example, at present, all Android Market-compliant devices must have a touchscreen, which eliminates MIPS-powered set-top boxes.
Can multiple processor-specific JNI libraries be packaged into a single app?
Yes. That is a key feature of the NDK.