[OpenWrt-Devel] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment

[Felix Fietkau]

On 2014-08-31 12:56, Nikos Mavrogiannopoulos wrote:
> On Sun, 2014-08-31 at 12:14 +0200, Felix Fietkau wrote:
> 
>> > To have small binaries is nice, but I guess that a growing amount of Openwrt 
>> > users are power users with modern routers with more flash space and having 
>> > interest for VPNs etc. And for them mips16 may have brought more trouble than 
>> > benefits.
>> I think only a small portion of our packages seem to have problems with
>> mips16, and turning it off selectively is very easy - so I don't
>> consider this a big deal. I think it makes sense to simply wait for bug
>> reports to show up and deal with those on a case by case basis.
> 
> I don't know if bug reports would help on that case. I had noticed that
> 2048-bit key generation with nettle+minigmp would take an enormous
> amount of time, but I just blamed the router's cpu. You'll only get bug
> reports from people who can compare with different toolchains and that's
> not a common case (not my case at least).
Still, it's usually only going to affect some corner cases.

>> If we delay using mips16 until core devs have gone through every single
>> package, it will never get done...
> 
> Well, space is much less of an issue in new embedded systems, but
> nevertheless the fix of having each package add a MIPS16 flag doesn't
> scale very well. The maintainer would have to do quite some testing
> (supposing that he has the specific hardware) and make benchmarks on
> with different toolchains to see whether that flag should be set or not.
> This of course will not happen and in the end, every package that
> depends on performance will just enable that flag. Wouldn't it make
> sense to introduce a performance critical flag instead that can also
> cover more cpus than mips, and would ease the maintainers job, as it
> would be more clear on which packages to enable the flag?
I don't think "performance criticial" is a good fit for a flag. In some
cases, performance critical code could actually work better with mips16
if cache footprint is the driving factor.
So far the only code I've seen where performance was significantly
affected was crypto related code...

- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel