Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121002134843.GV254@brightrain.aerifal.cx>
Date: Tue, 2 Oct 2012 09:48:43 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: musl for ARM

On Tue, Oct 02, 2012 at 03:27:28PM +0800, Brian Wang wrote:
> Hello all,
> 
> I am currently thinking of switching to musl from glibc for my target
> after some readings on musl.
> I would like some advice from musl experts:
>   * Does it support gettext stuff?
>   * Does it _boost_ the performance on a 400MHz arm926 device?  Or it
> is just smaller?
>     By _boost_, I mean if the user can actually feel the improvement
> in performance.

In general, if an application's perceived performance varies heavily
depending on libc, the application is probably doing something wrong
or at least naive. I can think of some exceptions of course, but this
advice is just to say that libc is probably not a place to look for
significantly improving overall performance. If there are libc
bottlenecks, you could probably get a lot more performance out of
changing the application.

The main exceptions I can think of are places where libc has the wrong
big-O: for example, O(n²) qsort or O(nm) strstr, or backtracking
regex implementations, can make completely-sane programs run extremely
slow on a bad libc. Note that musl and glibc are almost always
equivalent in this area; uclibc and dietlibc and perhaps others have
some problems here.

One area you can get vastly better performance with musl is
application startup overhead. Especially with static linking, but even
with dynamic linking if your only .so is libc, the startup time is
2-5x faster than glibc, which really makes a difference to the runtime
of shell scripts (like configure) that invoke tons of external
programs.

> I did try the musl cross project and successfully built a musl-based
> arm linux toolchain.
> My kernel (2.6.24) was built successfully (not tried it on my device yet).
> However, when building busybox, there are some header files clashes,
> resulting in conflicting types.
> An example of it:
> ---------------------
> In file included from
> /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/linux/kd.h:3:0,
>                  from console-tools/kbd_mode.c:23:
> /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/linux/types.h:12:26:
> error: conflicting types for ‘fd_set’
> In file included from
> /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/sys/time.h:9:0,
>                  from include/libbb.h:45,
>                  from console-tools/kbd_mode.c:22:
> /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/sys/select.h:25:3:
> note: previous declaration of ‘fd_set’ was here
> ---------------------

It looks like these kernel headers are not sanitized for compatibility
with userspace..?

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.