Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!news-2.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Gregory Ewing Newsgroups: comp.lang.python Subject: Re: Building CPython Date: Sat, 16 May 2015 12:55:51 +1200 Lines: 19 Message-ID: References: <7JN4x.37133$Q41.15375@fx25.am4> <6w35x.645690$I97.19867@fx31.am4> <874mnfunpn.fsf@elektro.pacujo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net TFFYzna75u68vs7bCrCH7Qk+tDOyp2TVguR6cyPPtAnB2G58j+ Cancel-Lock: sha1:J9571T44HueUShprM8OD32n2efA= User-Agent: Mozilla Thunderbird 1.0.5 (Macintosh/20050711) X-Accept-Language: en-us, en In-Reply-To: Xref: csiph.com comp.lang.python:90702 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. -- Greg