X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id 9883F5C592C for ; Wed, 25 Oct 2017 19:46:09 +0000 (GMT) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id 4FCB29E3132; Wed, 25 Oct 2017 19:46:09 +0000 (GMT) Received: from ncopa-desktop.copa.dup.pw (15.63.200.37.customer.cdi.no [37.200.63.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id B46779E149D; Wed, 25 Oct 2017 19:46:08 +0000 (GMT) Date: Wed, 25 Oct 2017 21:46:03 +0200 From: Natanael Copa To: =?ISO-8859-1?B?UHJ6ZW15cyphdyBQYXdlKmN6eWs=?= Cc: Subject: Re: [alpine-devel] force compile flag for musl? Message-ID: <20171025214603.00169caf@ncopa-desktop.copa.dup.pw> In-Reply-To: <15f542f8688.cf7ee9da1704.8790472834519953285@zoho.com> References: <20171025164614.14c4c57e@ncopa-desktop.copa.dup.pw> <15f542f8688.cf7ee9da1704.8790472834519953285@zoho.com> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, 25 Oct 2017 17:38:57 +0200 Przemys*aw Pawe*czyk wrote: > ---- On Wed, 25 Oct 2017 16:46:14 +0200 Natanael Copa wrote ----=20 > > I wonder what you think about overriding the -Os compile flag for musl,= =20 > > and hardcode it to -O2. =20 >=20 > I would be very careful with such changes. >=20 > 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. >=20 > 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. >=20 > 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. =20 >=20 > 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 pla= ce. It is from here: https://superuser.com/questions/1219609/why-is-the-alpine-docker-image-over= -50-slower-than-the-ubuntu-image BENCHMARK=3D"import timeit; print(timeit.timeit('import json; json.dumps(li= st(range(10000)))', number=3D5000))" # 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. > > =20 > > This means that we override whatever user as set CFLAGS to=20 > > in /etc/abuild.conf=20 > > =20 > > We already do this with zlib. =20 >=20 > 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 :) >=20 > > =20 > > What do you think? =20 >=20 > There were similar changes in aports for various applications over > recent months, but I haven't seen even one proof behind them. >=20 > 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. >=20 > Regards, > Przemek >=20 >=20 > > =20 > > diff --git a/main/musl/APKBUILD b/main/musl/APKBUILD=20 > > index 1938bbb3ca..193002186d 100644=20 > > --- a/main/musl/APKBUILD=20 > > +++ b/main/musl/APKBUILD=20 > > @@ -54,6 +54,8 @@ build() {=20 > > fi=20 > > =20 > > # note: not autotools=20 > > + # force -O2 compile flag for better performance=20 > > + CFLAGS=3D"-O2" \=20 > > LDFLAGS=3D"$LDFLAGS -Wl,-soname,libc.musl-${CARCH}.so.1" \=20 > > ./configure \=20 > > --build=3D$CBUILD \=20 > > =20 > > -nc =20 >=20 --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---