Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Sun, 17 May 2015 14:25:29 +0200
From: Jonas Wielicki <jonas@wielicki.name>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Building CPython
References: <7JN4x.37133$Q41.15375@fx25.am4>	<mailman.464.1431556504.12865.python-list@python.org>	<6w35x.645690$I97.19867@fx31.am4> <874mnfunpn.fsf@elektro.pacujo.net> <zR85x.441429$Zf4.246168@fx22.am4> <xpb5x.597872$X95.548374@fx10.am4> <crlglfFgf05U1@mid.individual.net> <Z2j5x.640864$ms.43141@fx30.am4> <crnisnF2efoU1@mid.individual.net>
In-Reply-To: <crnisnF2efoU1@mid.individual.net>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9xl4BPAaelMskGWGcv8SSTlILJ8L2p4fb"
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.90.1431866130.17265.python-list@python.org>
Lines: 66
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:90768

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--9xl4BPAaelMskGWGcv8SSTlILJ8L2p4fb
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 16.05.2015 02:55, Gregory Ewing wrote:
> BartC wrote:
>> For example, there is a /specific/ byte-code called BINARY_ADD, which
>> then proceeds to call a /generic/ binary-op handler! This throws away
>> the advantage of knowing at byte-code generation time exactly which
>> operation is needed.
>=20
> While inlining the binary-op handling might give you a
> slightly shorter code path, it wouldn't necessarily speed
> anything up. It's possible, for example, that the shared
> binary-op handler fits in the instruction cache, but the
> various inlined copies of it don't, leading to a slowdown.
>=20
> The only way to be sure about things like that is to try
> them and measure. The days when you could predict the speed
> of a program just by counting the number of instructions
> executed are long gone.

That, and also, the days where you could guess the number of
instructions executed from looking at the code are also gone. Compilers,
and especially C or C++ compilers, are huge beasts with an insane number
of different optimizations which yield pretty impressive results. Not to
mention that they may know the architecture you=E2=80=99re targeting and =
can
optimize each build for a different architecture; which is not really
possible if you do optimizations which e.g. rely on cache
characteristics or instruction timings or interactions by hand.

I changed my habits to just trust my compiler a few years ago and have
more readable code in exchange for that. The compiler does a fairly
great job, although gcc still outruns clang for *my* usecases. YMMV.

regards,
jwi



--9xl4BPAaelMskGWGcv8SSTlILJ8L2p4fb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVWIjBAAoJEMBiAyWXYliKd/cP/jkuvfNuNF/5WCjymR89t0Nt
/aoxcQzze/K7IhJAGS4T98kVonHjshvXrtfj/f6sCV++eOefw3LVCnylwrjjPoZm
1ZzpwA1CD23oz4lkGo4aJODDkO/9WoK9hqcXvq/AF/lA4Vn3R261tkhMzY3T98Vl
1jDheJu44rqe1Lt0XSB6IYvfmePY22LzqzLXGeTcDfNenXLYxe+U/IP6OusfzuKS
pFSd6TRa+UgMfpUI87k1VS3Ls7MwVlepTRi+OA45bJ/juhXVe+gXAG0pSPriAFPz
NlKvhw2bfGW2FgUZ1rcdcOdtcDtBPE/0IMnc3TXjv2i69f0/UK9zrw3Y64i26Z67
o4H8DRkQd8KxCSNEc4oXSdlWJpDM3yBzYXvbnhbcULvoLd+A8hpp3s+d7nW4aJkK
b0OWAAm/tP25Fc+knvhA/m9LeokOQ8sWVT2Bj0jd/TuZ66lqPOnHBylfjKZ76LaR
TJbw8SOvfSOSA6oa+QXy8bs39/4B8DKrkWWHBjnQ0qOO3TtFeKyJlLRCphPMUC2g
FfiBEPHNVSbQ9h8XsUSoJjDv0hVDgwCV8lPlKnJHnyIIFhIcHf6gA0SqSEHDlBvW
8eqgd/J/SKs4wpIIEe2l88l5gLv3NuYq3Pm9fC/CpfX0Z3RRmSm1qjDFU/h+ht1J
uCIpS78dDfTCp9FEGA1M
=WuvZ
-----END PGP SIGNATURE-----

--9xl4BPAaelMskGWGcv8SSTlILJ8L2p4fb--