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

Nikos Mavrogiannopoulos nmav at gnutls.org
Sun Aug 31 06:56:44 EDT 2014

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).

> 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?

openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list