[meta-raspberrypi] Why not enable hard floating point?

[meta-raspberrypi] Why not enable hard floating point?

[J. Tang]

The upstream meta-raspberrypi recipe builds an arm6 toolchain with only soft floating point. As an experiment, I enabled hard floating point by setting my DEFAULTTUNE to “armv6hf”. My code still ran correctly. Is there a reason why the meta-raspberrypi layer does not enable hard floating point?

-- 
Jason Tang  /  tang@jtang.org

Re: [meta-raspberrypi] Why not enable hard floating point?

[Andrei Gherzan]

Hello,

On Sat, Jan 10, 2015 at 10:38:50AM -0500, J. Tang wrote:
> The upstream meta-raspberrypi recipe builds an arm6 toolchain with only soft floating point. As an experiment, I enabled hard floating point by setting my DEFAULTTUNE to “armv6hf”. My code still ran correctly. Is there a reason why the meta-raspberrypi layer does not enable hard floating point?
>

Well we played a little with this in the past. And we realised that, at that
time at least, switching to hf didn't add any performace improvements. Did you
test anything that proves the contrary?

Thanks,

--
Andrei Gherzan

Re: [meta-raspberrypi] Why not enable hard floating point?

[J. Tang]

On Jan 14, 2015, at 15:36 , Andrei Gherzan <andrei@gherzan.ro> wrote:

> On Sat, Jan 10, 2015 at 10:38:50AM -0500, J. Tang wrote:
>> The upstream meta-raspberrypi recipe builds an arm6 toolchain with only soft floating point. As an experiment, I enabled hard floating point by setting my DEFAULTTUNE to “armv6hf”. My code still ran correctly. Is there a reason why the meta-raspberrypi layer does not enable hard floating point?
>> 
> 
> Well we played a little with this in the past. And we realised that, at that
> time at least, switching to hf didn't add any performace improvements. Did you
> test anything that proves the contrary?

In my case, I was re-compiling MAME for the Raspberry Pi. The code has a dependency on hf. Furthermore, Rasbian is built with hf.

-- 
Jason Tang  /  tang@jtang.org

Re: [meta-raspberrypi] Why not enable hard floating point?

[Mike Looijmans]

On 15-01-15 01:11, J. Tang wrote:
>
> On Jan 14, 2015, at 15:36 , Andrei Gherzan <andrei@gherzan.ro> wrote:
>
>> On Sat, Jan 10, 2015 at 10:38:50AM -0500, J. Tang wrote:
>>> The upstream meta-raspberrypi recipe builds an arm6 toolchain with only soft floating point. As an experiment, I enabled hard floating point by setting my DEFAULTTUNE to “armv6hf”. My code still ran correctly. Is there a reason why the meta-raspberrypi layer does not enable hard floating point?
>>>
>>
>> Well we played a little with this in the past. And we realised that, at that
>> time at least, switching to hf didn't add any performace improvements. Did you
>> test anything that proves the contrary?
>
> In my case, I was re-compiling MAME for the Raspberry Pi. The code has a dependency on hf. Furthermore, Rasbian is built with hf.

If the CPU has actual hard-float support, then enabling it should increase 
floating point performance by an order of magnitude (e.g. 100x faster or so).

If you don't see any real world performance improvements, My guess would be 
one of these cases:

-1- The compiler is already creating FPU instructions, based on other 
properties of the target platform. The "hf" tune only changes the ABI, so that 
floating point values are passed to/from libraries in normal registers instead 
of FPU registers. This has very little impact on performance (unless you have 
some very badly designed libs). You can check if this is the case by examining 
disassember output for a bit of FPU code, if you see instructions starting 
with "F" in there, it's using the ARM VFP.

-2- The CPU doesn't actually have floating point support and the kernel is 
emulating it for you. This allows the platform to run "hf" binaries, at a 
minor performance cost compared to completely doing the emulation in user 
space (libc).



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

Re: [meta-raspberrypi] Why not enable hard floating point?

[J. Tang]

On 2015-01-15, at 04:06, Mike Looijmans <mike.looijmans@topic.nl> wrote:

> -2- The CPU doesn't actually have floating point support and the kernel is emulating it for you. This allows the platform to run "hf" binaries, at a minor performance cost compared to completely doing the emulation in user space (libc).

From my understanding, the Raspberry Pi (at least the model B, which is what I have) has an FPU.

Would it hurt to at least mention in the top-level README of the meta-raspberrypi layer that a user could enable hard FP by setting the DEFAULTTUNE?

-- 
Jason Tang  /  tang@jtang.org

Re: [meta-raspberrypi] Why not enable hard floating point?

[Andrei Gherzan]

[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]

Hello,

On Fri, Jan 16, 2015 at 3:05 AM, J. Tang <tang@jtang.org> wrote:

>
> On 2015-01-15, at 04:06, Mike Looijmans <mike.looijmans@topic.nl> wrote:
>
> > -2- The CPU doesn't actually have floating point support and the kernel
> is emulating it for you. This allows the platform to run "hf" binaries, at
> a minor performance cost compared to completely doing the emulation in user
> space (libc).
>
> From my understanding, the Raspberry Pi (at least the model B, which is
> what I have) has an FPU.
>
> Would it hurt to at least mention in the top-level README of the
> meta-raspberrypi layer that a user could enable hard FP by setting the
> DEFAULTTUNE?
>
>
Definitely it wouldn't. But right now we have two options:
We can just throw a README line and that's it.
Or we can  investigate a little to see if in our current setup we actually
use FPU instructions or not. Following Mike's answer I would definitely
think that we are in case 1 where the compile based on the CPU
configuration figures out that we can use FPU instruction on this CPU
architecture. Right now, as being on vacation, I can really test on
binaries by dissembling code and check it by hand. Anybody who can do it
and provide some feedback? As well, some bench-marking would really make
sense here.

Thanks guys.

-- 
*Andrei Gherzan*

[-- Attachment #2: Type: text/html, Size: 2110 bytes --]

Re: [meta-raspberrypi] Why not enable hard floating point?

[Andrei Gherzan]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

On Sun, Jan 18, 2015 at 2:29 AM, Andrei Gherzan <andrei@gherzan.ro> wrote:

> Hello,
>
> On Fri, Jan 16, 2015 at 3:05 AM, J. Tang <tang@jtang.org> wrote:
>
>>
>> On 2015-01-15, at 04:06, Mike Looijmans <mike.looijmans@topic.nl> wrote:
>>
>> > -2- The CPU doesn't actually have floating point support and the kernel
>> is emulating it for you. This allows the platform to run "hf" binaries, at
>> a minor performance cost compared to completely doing the emulation in user
>> space (libc).
>>
>> From my understanding, the Raspberry Pi (at least the model B, which is
>> what I have) has an FPU.
>>
>> Would it hurt to at least mention in the top-level README of the
>> meta-raspberrypi layer that a user could enable hard FP by setting the
>> DEFAULTTUNE?
>>
>>
> Definitely it wouldn't. But right now we have two options:
> We can just throw a README line and that's it.
> Or we can  investigate a little to see if in our current setup we actually
> use FPU instructions or not. Following Mike's answer I would definitely
> think that we are in case 1 where the compile based on the CPU
> configuration figures out that we can use FPU instruction on this CPU
> architecture. Right now, as being on vacation, I can really test on
> binaries by dissembling code and check it by hand. Anybody who can do it
> and provide some feedback? As well, some bench-marking would really make
> sense here.
>

It was confirmed on another thread (
https://lists.yoctoproject.org/pipermail/yocto/2015-January/023201.html)
that there is no performance improvements while switching to HFP. This
basically proves what Mike Looijmans described in (1). So, we are on the
safe side with our current setup.


-- 
*Andrei Gherzan*

[-- Attachment #2: Type: text/html, Size: 2955 bytes --]