Live data from Hacker News

Pyjion – A Python JIT Compiler

trypyjion.com

91–100 of 126 posts

Re: Pyjion – A Python JIT Compiler

#92

Earlier quoted context omitted.

As an outsider this may be your perception, but this is not how python's documentation works. > These documents are just informal prose. Not true. They're the language spec. Every guaranteed behavior of python is described clearly and concretely in these documents. > Are they sound? Yes. > Does my implementation match what they say? Yes. > Does CPython even match it? Yes. > Does anyone know? Yes! There's a very rigor…

>> Are they sound? > Yes. That's great! Can you point me at the formal proof? I haven't seen it myself. > There's a very rigorous and thorough set of unit tests that specifically test an implementation's ability to match precisely the behavior described in these documents. How can you test against English prose? You can't. So someone's manually translated the prose into tests elsewhere I guess. Have they done that co…

> That's great! Can you point me at the formal proof? I haven't seen it myself.

Can you point me at the proof for the soundness of the documented behavior java or javascript or C++ docs? A cute little table isn't a substitute for soundness, and none of the languages you mentioned are mores soundly implemented (at least in their popular implementations).

> It's easy to see where these simple English descriptions aren't covering everything. To give you a practical example - look at https://docs.python.org/3/reference/datamodel.html#object.__... - 'should return False or True' - what if it doesn't? Where's that specified? Is it somewhere else in this document? That's the kind of practical issue we work with when implementing languages.

Cpython raises an exception, and in general, cpython is the spec unless otherwise specified is how things turn out.

> How can you test against English prose? You can't. So someone's manually translated the prose into tests elsewhere I guess. Have they done that correctly? How can we verify that? Was there any ambiguity when they were interpreting the English?

This is sort of a silly complaint. every spec is implemented in english prose[1]. That's why we end up with arguments about SHALL vs. MUST in the specs. Except in the rare cases where the spec is a test suite, which usually reduces to the case of cpython: the popular implementation is the spec (or maybe the popular implementation forks its test suite out into a different repo to make it more "independent")

[1]: Please don't make a irrelevant point about an obscure implementation of C that's implemented in agda and the "spec" is the proof of soundness or whatever, that's fundamentally the same as the implementation is the spec, especially given that said C implementation probably isn't ANSI compliant or whatnot.

Re: Pyjion – A Python JIT Compiler

#93

Earlier quoted context omitted.

>> Are they sound? > Yes. That's great! Can you point me at the formal proof? I haven't seen it myself. > There's a very rigorous and thorough set of unit tests that specifically test an implementation's ability to match precisely the behavior described in these documents. How can you test against English prose? You can't. So someone's manually translated the prose into tests elsewhere I guess. Have they done that co…

> That's great! Can you point me at the formal proof? I haven't seen it myself. Can you point me at the proof for the soundness of the documented behavior java or javascript or C++ docs? A cute little table isn't a substitute for soundness, and none of the languages you mentioned are mores soundly implemented (at least in their popular implementations). > It's easy to see where these simple English descriptions aren'…

> Can you point me at the proof for the soundness of the documented behavior java or javascript or C++ docs?

https://link.springer.com/book/10.1007/3-540-48737-9

Java does have a formal semantics, with a whole chapter on its soundness.

> in general, cpython is the spec

Well there we go - turns out the written document doesn't cover everything after all. A second ago we were at 'Every guaranteed behavior of python is described clearly and concretely in these documents.' Turns out not.

I'm not criticising Python as being exceptionally bad, but we can certainly do it much better.

Re: Pyjion – A Python JIT Compiler

#94
post #73

Earlier quoted context omitted.

Clearly PyPy has to produce executable code if it wants to jump into it. The CPU wouldn't understand if it were asked to jump into something that isn't executable code. > The point of the first futurama projection ...was to delight viewers with what would turn out to be a wonderful pilot episode?

It produces executable code ad hoc based on the dynamic environment. Not an executable. That's not the same thing.

I don't see how the frequency or laziness of the process makes a meaningful difference. It takes an interpreter, evaluates it with partial information (like, "type of x is integer"), and delays the rest till the execution is possible with the remaining information (like, "x is 7").

Re: Pyjion – A Python JIT Compiler

#95

Earlier quoted context omitted.

> That's great! Can you point me at the formal proof? I haven't seen it myself. Can you point me at the proof for the soundness of the documented behavior java or javascript or C++ docs? A cute little table isn't a substitute for soundness, and none of the languages you mentioned are mores soundly implemented (at least in their popular implementations). > It's easy to see where these simple English descriptions aren'…

> Can you point me at the proof for the soundness of the documented behavior java or javascript or C++ docs? https://link.springer.com/book/10.1007/3-540-48737-9 Java does have a formal semantics, with a whole chapter on its soundness. > in general, cpython is the spec Well there we go - turns out the written document doesn't cover everything after all. A second ago we were at 'Every guaranteed behavior of python is…

> Java does have a formal semantics, with a whole chapter on its soundness.

No, there's a chapter on the soundness of its type system. The spec being sound and the type system being sound are very different things. If we consider typescript to be JS's type system, then JS's type system is unsound. If we consider cpython in isolation, under the definition you're using, cpython cannot be unsound, as it is untyped, QED.

If you're talking about whether the language's type system is sound, asking "These documents are just informal prose. Are they sound?" isn't even a well defined question.

> I'm not criticising Python as being exceptionally bad, but we can certainly do it much better.

You absolutely were when you said "But I wish Ruby and Python were this explicit and easy to understand!"

Re: Pyjion – A Python JIT Compiler

#96

Earlier quoted context omitted.

Have you seen the Python docs which have pages on the execution model and data model, with notes in implementation details? https://docs.python.org/3/reference/executionmodel.html https://docs.python.org/3/reference/datamodel.html

I guess you are trying to imply that those documents cover a formal-enough description of what the execution and data model is. Well, even for the section "names" it just forgets to say if imported and non-imported names all share the same encoding and which should it be - just a nitpick, but with less than 5 seconds. Do you know that there are some behavioral limitations of dict that arise from a specific optimizati…

> Well, even for the section "names" it just forgets to say if imported and non-imported names all share the same encoding and which should it be - just a nitpick, but with less than 5 seconds

https://www.python.org/dev/peps/pep-0263/

Names aren't unique.

> Do you know that there are some behavioral limitations of dict that arise from a specific optimization in the implementation in C of dictionary iterators?

I'm rather curious what you're referring to here, do you mean dict-ordering, or something else?

Re: Pyjion – A Python JIT Compiler

#97
post #57

Earlier quoted context omitted.

It certainly is good, but I've never found a great dev setup. It seems like you have to force a full recompile of all cython in the project any time you make a change. At least that was the stated process for the statsmodels library. And it was always a little unclear whether I was running the latest code or hadn't yet actually compiled it.

I've never used cython before. Is it 1-to-1 with standard Python? If so, can you do development using the regular Python binary, and leave the compilation step as a pre-commit operation?

The workflow with Cython is that it produces native python modules (e.g. .so shared objects / .dll dynamic link libraries) that the python interpreter can import.

So if you change some of your Cython code, for it to be used at runtime you need to invoke the Cython build tools to rebuild the new version of your python native module.

I usually use Cython for a small core of compute heavy operations, and leave the rest of the project as pure python. That way I only need to rebuild Cython code if I change something inside that small core.

> Is it 1-to-1 with standard Python?

Not for the best speedups, no.

E.g. you might be able to get a modest speedup, say 50%, taking a pure python file, renaming it to *.pyx, and getting Cython to compile it. But that's not why I use Cython. I use it when I have compute-heavy code that I want to run at native speed (think matrix-vector product type stuff), by carefully rewriting in Cython, thinking carefully about memory allocation, data structures (prefer C arrays!) and performance, it is fairly achievable to get a 500x speedup.

Cython relies on you writing specialised Cython code that is quite close to C code -- strongly typed Cython variables work like statically typed C variables, not dynamically typed Python names. You end up with Cython code that cannot be executed as if it were normal Python code by a python interpreter.

But, Python code can usually not be executed very efficiently, whereas Cython can translate small loops of strongly-typed numeric code into small loops of strongly-typed C code, which can often compile to very small loops of native CPU instructions, which then run blazing fast.

Under the hood, Cython works by translating the not-quite-python code into C code that uses the python interpreter's C extension API. Then it compiles the C code into a python native module using a C compiler.

Re: Pyjion – A Python JIT Compiler

#98

Earlier quoted context omitted.

Can you link me to some sources? I'm not familiar with PyPy but I thought it's a normal tracing JIT. In fact quick googling shows a blog post explicitly saying PyPy does NOT use PE: https://www.pypy.org/posts/2018/09/the-first-15-years-of-pyp... . Besides not every PE instance is a Futurama Projection.

You're right, PyPy _used_ to base it's wizardry on PE (I don't know if it's Futurama or not, that's honestly the first time I hear of that term), but now they are using something called meta-tracing JIT, where, instead of JIT-tracing the program that your language's source describes, they JIT-trace your interepreter while it's running your language's source . The extremly cool and awesome thing about this is that thi…

[deleted]

Re: Pyjion – A Python JIT Compiler

#99
post #31

Earlier quoted context omitted.

It can run most unmodified Python code, but it needs types for the big speedups.

That's misleading as normal type annotations don't give you any performance benefit at all and you may need to do a lot more than just add type annotations. I think it's far more accurate to say that Cython is a programming language of its own that is a hybrid of Python and C++, that happens to produce CPython extension modules when compiled. The performance benefits are really achieved by incrementally changing your…

> The performance benefits are really achieved by incrementally changing your Python code to something that looks a lot more like C(++)

I completely agree. Cython can become quite attractive if your alternative is "write a python extension library by hand in C / C++". I first started using Cython after doing exactly that, writing my extension library in C, then realising that Cython might save a lot of work in generating the bindings and packaging/distribution -- it did, and it ran at exactly the same speed as my pure C library with hand crafted python bindings. After that I've been pretty excited about Cython.

If you've got a python program that needs to do a core of compute-heavy work, if you were to optimise this by writing a C / C++ library for python to use, the work would be: (i) think hard about how the library design will enable performance, (ii) implement that high performance library in C / C++ , (iii) figure out the interface so that python can call into the library, and (iv) figure out how to package and distribute the library so it can be used by python programs.

Cython doesn't really help with parts (i) designing for performance or (ii) writing that high performance code. But it helps a lot with parts (iii) and (iv), generating Python bindings and producing wheel archives that can be managed by existing python package management tooling.

Re: Pyjion – A Python JIT Compiler

#100
post #97

Earlier quoted context omitted.

I've never used cython before. Is it 1-to-1 with standard Python? If so, can you do development using the regular Python binary, and leave the compilation step as a pre-commit operation?

The workflow with Cython is that it produces native python modules (e.g. .so shared objects / .dll dynamic link libraries) that the python interpreter can import. So if you change some of your Cython code, for it to be used at runtime you need to invoke the Cython build tools to rebuild the new version of your python native module. I usually use Cython for a small core of compute heavy operations, and leave the rest…

Thanks for pointing this out. I didn't realize this until I read further into this thread and started looking at optimized cython projects. Now I understand what you're talking about.
Post reply on HN