Re: [Python-Dev] Is there a reference manual for Python bytecode?

[Sturla Molden]

Brett Cannon  wrote:

> Ned also neglected to mention his byterun project which is a pure Python
> implementation of the CPython eval loop:  href="https://github.com/nedbat/byterun";>https://github.com/nedbat/byterun

I would also encourage you to take a look at Numba. It is an LLVM based JIT
compiler for Python bytecode, written for hardcore numerical algorithms in
Python. It can often achieve the same performance as -O2 in C after a short
burn-in while inferring the types of the arguments and variables. Using it
is mostly as easy as adding an @numba.jit decorator to the function we want
to accelerate. Numba is rapidly becoming what Google's long dead swallow
should have been.

:-)

Sturla

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is there a reference manual for Python bytecode?

[Nick Coghlan]

On 28 December 2015 at 11:00, Erik  wrote:
> On 28/12/15 00:41, Guido van Rossum wrote:
>>
>> Can you show the diffs you have so far? Somebody's got to look at your
>> code.
>
> Sounds like it's not a well-known symptom then.

The symptom is well known (at least to folks that have worked on the
compiler and eval loop since the switch to importlib as the import
system implementation), but the circumstances where it can arise are
*very* limited. Specifically, being unable to load the import system
while working on CPython is usually a sign that:

1. The interpreter's bytecode generation is inconsistent with the
implementation of the eval loop
2. importlib._bootstrap includes code that triggers the inconsistent
bytecode processing path
3. Freezing importlib._bootstrap to create _frozen_importlib thus
produces a frozen module that won't load with the given eval loop
implementation

If you're not hacking on bytecode generation or the eval loop (1), or
your changes to the bytecode generator and/or eval loop don't impact
the code in importlib._bootstrap (2), then you won't see this kind of
bug (3).

> I agree, but that Somebody
> should be me (initially, at least) - I don't want to waste other people's
> time if I made a silly mistake.

In this particular case, it's hard to help debug the error without
being able to see both the new code generation changes and the
corresponding eval loop changes.

It's also the case that to rule out the bootstrapping cycle as a
potential source of problems, you can try the following manual dance:

1. Revert to a clean checkout and rebuild
2. Apply the eval loop changes, and rebuild
3. Apply the code generation changes, and rebuild

That generally *shouldn't* be necessary (it's why there's a separate
build step to freeze the import system), but it can be a useful
exercise to help figure out the source of the "unknown opcode"
problem.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com