Mail archive
alpine-devel

Re: [alpine-devel] force compile flag for musl?

From: Natanael Copa <ncopa_at_alpinelinux.org>
Date: Wed, 25 Oct 2017 21:46:03 +0200

On Wed, 25 Oct 2017 17:38:57 +0200
Przemys*aw Pawe*czyk <przemoc_at_zoho.com> wrote:

> ---- On Wed, 25 Oct 2017 16:46:14 +0200 Natanael Copa <ncopa_at_alpinelinux.org> wrote ----
> > I wonder what you think about overriding the -Os compile flag for musl,
> > and hardcode it to -O2.
>
> I would be very careful with such changes.
>
> There is misconception that the higher optimization level, the faster
> code is generated. That is the general -Olevel idea, but not what is
> seen in practice. Gains (or losses) from higher optimization levels
> vary between archs and obviously depend on the code that is being
> optimized.
>
> Smaller code, beside being smaller, is also more cache-friendly, so -Os
> can be faster than -O2 and often is. OTOH higher optimization levels
> for x86-64 usually tend to give better results than on other archs.
>
> There is no rule. It all depends on:
> - source code,
> - compiler,
> - platform.

As I understand -Os and -O2 are basically the same thing, with the
difference that -O2 enables some more alignments.

> > I think this makes sense since the functions in libc are so often
> > used that we want trade better performance at the cost of slightly
> > bigger binary.
>
> This makes sense if we really get better performance with -O2 on all
> platforms AL supports. And to be able to confirm that, it has te be
> measured.

You are right, of course.

I did a quick test with the code that made me think of -O2 in the first place. It is from here:
https://superuser.com/questions/1219609/why-is-the-alpine-docker-image-over-50-slower-than-the-ubuntu-image

BENCHMARK="import timeit; print(timeit.timeit('import json; json.dumps(list(range(10000)))', number=5000))"

# with -O2

$ for i in $(seq 0 6); do python3 -c "$BENCHMARK"; done
8.284425613994244
8.354899992002174
8.359624709992204
8.392496702988865
8.3223694319895
8.285188248992199
8.294311116012977

# with -Os

$ for i in $(seq 0 6); do python3 -c "$BENCHMARK"; done
8.267152725020424
8.260578833986074
8.232940819987562
8.224149581015809
8.27815192801063
8.31035227200482
8.29849099801504

So it looks that for this specific workload, -Os is actually slightly
faster.

It just highlights the point that you need to actually measure before
trying to optimize.


> >
> > This means that we override whatever user as set CFLAGS to
> > in /etc/abuild.conf
> >
> > We already do this with zlib.
>
> zlib is a different beast, because it's computational software. It's
> much more natural to see gains from higher -Olevel in that kind of
> apps.

I'm glad to hear that I'm not totally stupid :)

>
> >
> > What do you think?
>
> There were similar changes in aports for various applications over
> recent months, but I haven't seen even one proof behind them.
>
> Performance improvements are imporant, and they may come from simply
> bumping optimization level, but it should be verified, not blindly
> assumed.

Yeah, lets keep -Os and only change if its tested to have any impact.


>
> Regards,
> Przemek
>
>
> >
> > diff --git a/main/musl/APKBUILD b/main/musl/APKBUILD
> > index 1938bbb3ca..193002186d 100644
> > --- a/main/musl/APKBUILD
> > +++ b/main/musl/APKBUILD
> > _at_@ -54,6 +54,8 @@ build() {
> > fi
> >
> > # note: not autotools
> > + # force -O2 compile flag for better performance
> > + CFLAGS="-O2" \
> > LDFLAGS="$LDFLAGS -Wl,-soname,libc.musl-${CARCH}.so.1" \
> > ./configure \
> > --build=$CBUILD \
> >
> > -nc
>



---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Wed Oct 25 2017 - 21:46:03 GMT