All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Looijmans <mike.looijmans@topic.nl>
To: <yocto@yoctoproject.org>
Subject: Re: [meta-raspberrypi] Why not enable hard floating point?
Date: Thu, 15 Jan 2015 10:06:02 +0100	[thread overview]
Message-ID: <54B782FA.9040109@topic.nl> (raw)
In-Reply-To: <B16CA82B-7834-419F-9E84-669E8F9B6779@jtang.org>

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/



  reply	other threads:[~2015-01-15  9:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-10 15:38 [meta-raspberrypi] Why not enable hard floating point? J. Tang
2015-01-14 20:36 ` Andrei Gherzan
2015-01-15  0:11   ` J. Tang
2015-01-15  9:06     ` Mike Looijmans [this message]
2015-01-16  2:05       ` J. Tang
2015-01-18  0:29         ` Andrei Gherzan
2015-01-25 22:27           ` Andrei Gherzan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54B782FA.9040109@topic.nl \
    --to=mike.looijmans@topic.nl \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.