A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-July/007611.html below:

[Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment)

[Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment)Thomas Wouters thomas@xs4all.net
Fri, 28 Jul 2000 17:32:56 +0200
On Fri, Jul 28, 2000 at 11:26:46AM -0400, Eric S. Raymond wrote:

> >            LOAD_FAST(124) :   19323126 ================================
> >           SET_LINENO(127) :   15055591 ========================

> 1. That looks as close to a Poisson distribution as makes no difference.
>    I wonder what that means?

It means there's still room for optimization! Other than that, probably not
much. I also think that the similarity vanishes if you take into account
that SET_LINENO does nothing, and LOAD_FAST is a basic operation and should
be grouped with LOAD_NAME and LOAD_GLOBAL.

> 2. Microtuning in the implementations of the top 3 opcodes looks indicated,
>    as they seem to constitute more than 50% of all calls.

Actually, I believe there was talk of removing SET_LINENO altogether... or
am I mistaken in that ? In any case, you can do it by using -OO.

> 3. On the other hand, what do you get when you weight these by average
>    time per opcode?

My guess is that *_NAME moves on up, as they already are pretty high up, and
BINARY_* and UNARY_*, go *way* up: imagine all those classes that implement
__add__ and __not__. Even if you have but a few of those calls, they
effectively are (Python) function calls. In other words, those are pretty
meaningless.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4