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
signature.asc
Description: OpenPGP digital signature
-- https://mail.python.org/mailman/listinfo/python-list
