Building CPython

[Jonas Wielicki]

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.
> 
> 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.
> 
> 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’re 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20150517/e1e08da1/attachment.sig>