30 Jun
2011
30 Jun
'11
12:47 a.m.
On 06/29/2011 10:33 PM, Nick Copeland wrote:
I don't know what syscall you are talking about.
When you build with the android NDK, you can choose to compile for armeabi, for
armeabi-v7a or for both. If you only build for the later, then your app is not
visible to non ARMv7 devices on the market. I can't remember what happens if you
try to install the APK manually on an ARMv5 device, but I think this fails or
doesn't run.
If the app's built for both ABIs, then the package installer installs the proper
set of libraries provided by your app, either armeabi or armeabi-v7a depending
on the hardware.
Also, there's a small library provided by the NDK, called cpu-features, which
allows you to detect CPU features at run time. I used that and rely on it to
activate certain features. It works great.
A factor of 10 or 20 over hard floats? Sound about right? The factor
1000 is for code
that uses FPU instructions on systems without the FPU support. That I
would call
insanely slow but you can choose which way you go here.
AFAIK, on Android, there's no such thing as executing FPU instructions on
devices without an FPU, unless you are doing something very weird.
This 1000 factor and the syscalls you mention is something I never heard about,
which is maybe true in general about ARM, but which doesn't happen in practice
on Android, if you use the standard build tools and OS.
That said, a factor of 10 or 20 is enough for me to call it insane, yes :p
Okay, right, that's interesting. But, well, you got plenty of FPUs out there,
and you just need a single line in a makefile to use them. That was my point.
--
Olivier
No, when
building with Android NDK using the armeabi-v7a ABI, hard
floats are
used. This works on ARMv7, which means a lot of
devices, and certainly the
majority.
But then every other system gets the rough 1000 factor performance hit
that started
this thread since all other CPU have to do a system call to execute the
float operation.
Designing for a single handset family is not that scalable. The ARM
softfloat overhead is not that great and the coding required to get
access to the GPUs is suitable that developers will implement them
for optimisations.
Soft floats are insanely slow on Android in my experience. You got an FPU
on most devices, you can compile for hard floats,
activate ARM
NEON if you wish too, and even check for cpu
features at runtime. I
don't see
why you want to use the GPU for optimization.
Man, the recent chipsets have 6 of these pipelines - designed for
graphics processing
but sitting there waiting for audio DSP.