Genesi's Hardfloat Optimizations


Looks interesting that's for sure.


He says in the video that the api is already release? Maybe someone should take an application already compiled and recompile it to see if it makes a real world difference on the panda?


Definitely keep an eye on this!
 
Last edited by a moderator:
He says in the video that the api is already release?
Pretty sure he's talking about EABI, check out this and this on the Debian Wiki.


When you want to use hard floats, you need to tell the compiler what FPU to use for it. Besides the software FPU (either leaving it to the system or to the compiler's own implementations) there's VFP(lite), and you can use NEON for single precision as well.


At some forum talk I found via Google they said that the VFPlite of the Cortex-A8 is pretty useless because it's rather slow, NEON would be the only way to get a good FP performance. The VFP of the Cortex-A9 as well as its NEON unit are supposed to be much faster, and I'm pretty sure those are what he's pointing at.
 
Its a re-compile of the whole OS to use an ABI that puts floating-point registers in floating-point registers, and not packed (and thus needing gatekeeping between calls) into integer registers. The reason the ARM ABI doesn't do this in the first place, is because not all ARM implementations have FP registers ..


This would be good for us, too, btw, but would break compatibility with Angstrom methinks .. ;)
 
He says in the video that the api is already release?
Pretty sure he's talking about EABI, check out this and this on the Debian Wiki.


When you want to use hard floats, you need to tell the compiler what FPU to use for it. Besides the software FPU (either leaving it to the system or to the compiler's own implementations) there's VFP(lite), and you can use NEON for single precision as well.


At some forum talk I found via Google they said that the VFPlite of the Cortex-A8 is pretty useless because it's rather slow, NEON would be the only way to get a good FP performance. The VFP of the Cortex-A9 as well as its NEON unit are supposed to be much faster, and I'm pretty sure those are what he's pointing at.


Its a re-compile of the whole OS to use an ABI that puts floating-point registers in floating-point registers, and not packed (and thus needing gatekeeping between calls) into integer registers. The reason the ARM ABI doesn't do this in the first place, is because not all ARM implementations have FP registers ..


This would be good for us, too, btw, but would break compatibility with Angstrom methinks .. ;)

That's interesting - I use EABI for PandaBAS, but as FPC only supports softfp for floating point values passed by registers I can't use hardfp calls... I also enabled VFPv3 (not VFPlite) as NEON isn't in FPC at present, and got quite an enormous speed boost - on the order of 2 or 3 times the performance in FP code.


D.
 
This as confusing as it is interesting. As far as I am aware there are two ABI implementations for ARM, with debian supporting both (calling them different architectures - arm and armel).


OABI - the 'OLD' ABI - compiles everything with hardfloat. Always quite slow on most ARM systems because almost none had floating point units, so they have to trap the unsupported hardfloat instructions after they aren't recognised by the CPU, and then emulate them.


EABI - the new 'Embedded' ABI - supports mixing hardfloat and softfloat, default is softfloat. Generally much faster on most ARM systems because (until recently) they mostly didn't have floating point units. So the compiler builds code that emulates floating point to begin with, meaning the kernel doesn't have to trap unrecognised instructions and emulate them itself which is very slow. I think only kernels from around 2.6.16, and from a certain version of glibc onwards I believe, support EABI. Your toolchain is generally built for one or the other as well.


It seems what they are talking about must be using EABI (which is what most everything, including angstrom, ueses now), but just compiling everything with hardfloat and neon &/or VFP.


If I'm understanding this right they haven't really made a breakthrough so much as recompiled the OS with gcc optimisations for the processor in their product. The confusing part is that they make this sound like a new ABI or something really clever.


But then I didn't watch the whole video, so maybe I'm wrong somewhere.


I have no idea what angstrom does right now though, or whether it would break compatibility (I actually suspect not - but uncertain).
 
isn't it exactly the kind of thing you can achieve using gentoo on the pandora? (ps: it's a question to the people working on it :) )
 
Back
Top