Re: hf/sf [Was Re: CVS commit: pkgsrc/misc/raspberrypi-userland]

[Matt Thomas <matt%3am-software.com@localhost>]

On Nov 12, 2013, at 11:47 AM, Michael van Elst <mlelstv%serpens.de@localhost> 
wrote:

> matt%3am-software.com@localhost (Matt Thomas) writes:
> 
> 
>> On Nov 11, 2013, at 10:08 PM, Michael van Elst 
>> <mlelstv%serpens.de@localhost> wrote:
> 
>>> The "slowdown" is already enormous due to lack of floating point
>>> hardware. That's why emulating the FP hardware is a very common
>>> way to handle this situation, just look at the other platforms.
> 
>> The exception handling is much costlier than doing a softfloat call.
> 
> You missed the second paragraph.

No I didn’t.

>> It’s also adding kernel bloat.
> 
> Indeed, a little bit of kernel bloat compared to a dozen userlands
> and a dozen package repositories that require building and testing.

There are a lot of floating point and load/store instruction variants on ARM.  
It’s not “a little bit” of code, it’s a lot.  I have 

from http://mail-index.netbsd.org/port-powerpc/2012/09/26/msg003275.html

> On a P2020, a build.sh distribution for evbppc took 6.2% less time on a 
> softfloat userland .vs. hardfloat userland with kernel-emulation.
> 
> 10h55m32s (soft) vs. 11h38m50s (hard)

Doing a release build is not a floating point intensive workload yet it 
incurred a significant amount of overhead.  The platforms without FP are going 
to be the slowest so emulating FP would make then even slower.

When it comes to building a system I am willing to incur a slower build or 
consume more resources in order to get a faster system.  Spend the time upfront 
to get things to as fast as possible.  My builds might be slower or needs more 
space for packages, but the resultant system will run faster.  That seems to be 
a tradeoff worth making.