36 replies to this topic

[samsamsam]

Hello,

 

The STB ET4000  based on SoC bcm7358 which do not have FPU unit, use toolchain for Hardware float. 

In particular for code that uses float operation this is performance killer.

 

So,  why toolchain for  Hardware float is used for building libs, binaries .etc?

 

What is the reason?

 

Regards,

SSS

[athoik]

Hi SSS,

OpenPLi fixed that, for all receivers it supports. See DEFAULTTUNE = "mips32el-nf".

https://github.com/X...ine/et4x00.conf

Most probably you are using OE-A build https://github.com/o...lude/etxx00.inc, https://github.com/o...ine/et4x00.conf

They can fix it at any time, since they keep their own BSP layer.

Edited by athoik, 29 November 2015 - 07:21.

[MiLo]

Even if you use hardfloat, the kernel will emulate it, and the performance is comparable to the softfloat implementation. That is why hardfloat is the default for MIPS systems, even for those without FPU. The softfloat stack is only slightly faster. And in E2, very little floating point is ever used anyway.

[Erik Slagter]

Still when we separated the build it solved some mysterious problems. Maybe the emulation isn't perfect or it has implications for the abi/calling convention, like you mentioned earlier.

 

Anyway I'd very much recommend against buying a STB using a SoC without FPU, because currently many external applications and plugin assume binary compatibility (wrongly...). As soon as the ARM-based SoC come, that assumption will be rendered invalid completely.

Edited by Erik Slagter, 29 November 2015 - 10:07.

[samsamsam]

 

Even if you use hardfloat, the kernel will emulate it, and the performance is comparable to the softfloat implementation. That is why hardfloat is the default for MIPS systems, even for those without FPU. The softfloat stack is only slightly faster. And in E2, very little floating point is ever used anyway.

 

 

Yes I know, it is handled by CPU exception.

My tests give different result.

I just link statically my program with libraries, all builded with "-msoft-float", and works much faster (it operate on float numbers). But you probably know better.

 

 

Regards,

SSS

Edited by samsamsam, 29 November 2015 - 10:11.

[MiLo]

I'm just relaying what I was told when I informed why hardfloat was default for openembedded. If you have proof to the contrary, provide it and help the rest of the wold get smarter.

[christophecvr]

I looked up a lot about this issue.

 

But basically. And this comes from real experts.

 

If a processor does have a fpu You should use it and use hardfloat. It even brings all more stable and faster . Much more powerfull and better for energy and cpu heat.

 

If a processor does not have a fpu yes most kernels do have a emulation, but it's not so stable and very processor intensif. It's really adviced to use softfloat.

 

This means samsamsam and MiLo are right.

 

It's not a bad idea to perhaps implement a build one for all cpu with fpu stb's using hardfloat  and one with for non fpu cpu stb's using softfloat.

 

But for that think the openembedded team should be convinced. 

[MiLo]

It's not a bad idea to perhaps implement a build one for all cpu with fpu stb's using hardfloat  and one with for non fpu cpu stb's using softfloat.

That is what we have been doing for years at OpenPLi. Not because using soft-float binaries make a huge difference, but just to squeeze that last bit of performance out of it.

I never bothered to benchmark it, so I'd be curious as to what the results would be (that is, running hard vs soft float on a machine without FPU. On a machine with FPU that'd be a silly experiment.).

[samsamsam]

I have not wole E2 with all libs and binaries compiled with soft float, so I do not know what will be the real yield for E2.

Maybe you're right and if E2 not use float numbers there will not be performance experience.

[christophecvr]

Yes it all depends on how much float is used.

 

There are experts wich made benchmarks on it and off course then with software specially written to accentuate differences. Mostly those programs come from cpu manufacturers . (in dutch they say ge moet daar een korreltje zout bij nemen )

 

However what apart from such tests is true.

 

If You have an fpu and use sofloat some weird issues may happen

If You do not have a fpu and do use hardfloat some weird issues may happen.

 

In general the performance in both cases does not make that big difference.

 

Like You said

 

With fpu use hardfloat to squeeze max performance out off the binary s and also the sometimes weird things do not happen.

Without fpu use sofloat.

 

There was even somewhere a article about it from Linuz Torvald. Yes he can be very radicale. I can't find it anymore.

But he wrote to stop with those emu's and hacks in core to cover the non fpu processors and just use the right compile settings hard or softfloat end off line.  

[samsamsam]

If the softfload code is mixed with hardfloat for example binary is builded with softfloat but links libraries with hard float then strange thinks can happen, because foto float use different register than hardfloat as the function arguments.

[christophecvr]

If the softfload code is mixed with hardfloat for example binary is builded with softfloat but links libraries with hard float then strange thinks can happen, because foto float use different register than hardfloat as the function arguments.

That's why You must use the correct compile settings versus cpu. And that's all about linux this indeed for all library's and binaries . That's also the reason that we use open source software. And the closed source software should be made for both options. (means one lib or bin for the fpu cpu and one for the non fpu cpu)

 

The base linux core on it is made for that. If a cpu type is with fpu use hardfloat, if not use softloat and all problems are gone. All weird issues are gone and the max perfo is squeezed out of the cpu. Whitout overheating due to the weird and unneeded calculations .

Edited by christophecvr, 29 November 2015 - 16:11.

[Erik Slagter]

I don't understand the fuss. It's not like enigma is going to have to calculate primes or doing video encoding using floats. First concern should be stability and that's what we've choosen for.

 

But if anyone can't resist benchmarking the whole lot, please go ahead and share the figures. Don't forget to clean out the whole build directory and sstate-cache directory to make sure everything is built in one mode.

[MiLo]

Uh, guys to get things clear, on the CURRENT OpenPLi:

All boxes with FPU use hard float (abi and code) exclusively. It uses the FPU for calculations and uses the FPU registers to exchange data between libraries.

All boxes without FPU use soft float exclusively. (That means the et4000 too, yes.)

You cannot do better than that. It's the optimal thing to do, and we have already been doing that for ages.

[MiLo]

Up until recently, the Kernel's only interest in FPU usage has been that it needed to be aware of programs using the FPU so it can properly save/restore the FPU state when switching tasks.
The kernel itself didn't use any floating point calculations anywhere.

Recently, the kernel is also using multiple data instructions, and most CPUs (at least the ARM and x86 families all do) classify these as 'floating point' operations. The kernel uses specific calls in its code to mark paths that need the FPU as such, so that it knows when to store/retrieve the userspace FPU status.

[Erik Slagter]

Still a non-issue really.

[MiLo]

(For boxes with ARM CPU, the OpenEmbedded default is to use hard-float if available for calculations, but use the soft-float abi everywhere, and we haven't changed that default.)

[samsamsam]

So, I probably use wrong bb? Because when I use gcc from ganereted toolchain with option -msoft-float I have error suggesting that this is toolchain with hardfloat support only.

[MiLo]

Within OE, you should never have to bother about which CPU specific options to pass to GCC. If you think you need to pass "-msoft-float" manually, you're doing something wrong.

[samsamsam]

Is option "-msoft-float" is correct or not?

So, even if it is default with gcc build based on OE adding it should not give an error about missing sotfloat header.

 

At least with gcc provied by BRC this option can be added and works.

 

So, what I am doing wrong?