Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Python fast – Adventures with mypyc

blog.meadsteve.dev

Post reply on HN
Print view View original

41–50 of 95 posts

Re: Making Python fast – Adventures with mypyc

#41

Post by zzzeek »

chrisseaton wrote: post #29
zzzeek wrote: post #28

Earlier quoted context omitted.

> It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API). this is misleading, if one sees the phrase "interpreter" as that code is represented as syntax-derived trees or other datast…

Bytecode is just another data structure that you traverse at runtime to produce results. It's a postfix transformation of the AST. It's still an interpreter.

so you'd call the pre-JIT JVM an "interpreter" and you'd call Java an interpreted language?

Re: Making Python fast – Adventures with mypyc

#42

Post by zzzeek »

chrisseaton wrote: post #33
an1sotropy wrote: post #31

Earlier quoted context omitted.

Well, ok, but then isn't a CPU is also just an interpreter, traversing the object code text of compiled code?

We don't normally call hardware or firmware implementations an 'interpreter'. Almost all execution techniques include some combination of compilation and interpretation. Even some ASTs include aspects of transformation to construct them from the source code, which we could call a compiler. Native compilers sometimes have to interpret metadata to do things like roll forward for deoptimisation. But most people in the f…

I call it "bytecode interpreted" to distinguish it from traditional parse-tree interpretation such as Perl 5 and others

Re: Making Python fast – Adventures with mypyc

#43

Post by detaro »

zzzeek wrote: post #28
peterkelly wrote: post #11

Earlier quoted context omitted.

I'm well aware of V8 and pypy. I also really like Python as a language, especially with mypy. It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API). There is a really important (if…

> It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API). this is misleading, if one sees the phrase "interpreter" as that code is represented as syntax-derived trees or other datast…

That's not misleading, that's standard terminology. an interpreter using bytecode is still an interpreter.

Re: Making Python fast – Adventures with mypyc

#44

Post by chrisseaton »

zzzeek wrote: post #41
chrisseaton wrote: post #29

Earlier quoted context omitted.

Bytecode is just another data structure that you traverse at runtime to produce results. It's a postfix transformation of the AST. It's still an interpreter.

so you'd call the pre-JIT JVM an "interpreter" and you'd call Java an interpreted language?

> so you'd call the pre-JIT JVM an "interpreter"

Yeah? I think almost everyone would?

> and you'd call Java an interpreted language?

Java is interpreted in many ways, and compiled in many ways, as I said it's complicated. It's compiled to bytecode, which is interpreted until it's time to be compiled... at which point it's abstract interpreted to a graph, which is compiled to machine code, until it needs to deoptimise at which point the metadata from the graph is interpreted again, allowing it to jump back into the original interpreter.

But if it didn't have the JIT it'd always be an interpreter running.

Re: Making Python fast – Adventures with mypyc

#45

Post by [deleted] »

zzzeek wrote: post #42
chrisseaton wrote: post #33

Earlier quoted context omitted.

We don't normally call hardware or firmware implementations an 'interpreter'. Almost all execution techniques include some combination of compilation and interpretation. Even some ASTs include aspects of transformation to construct them from the source code, which we could call a compiler. Native compilers sometimes have to interpret metadata to do things like roll forward for deoptimisation. But most people in the f…

I call it "bytecode interpreted" to distinguish it from traditional parse-tree interpretation such as Perl 5 and others

[deleted]

Re: Making Python fast – Adventures with mypyc

#48

Post by raphaelrk »

Speaking of python performance, I recently benchmarked "numpy vs js" matrix multiplication performance, and was surprised to find js significantly outperforming numpy. For multiplying two 512x512 matrices:

    python
      numpy:               ~3.30ms
      numpy with numba:    ~2.90ms

    node
      tfjs:                ~1.00ms
      gpu.js:              ~4.00ms
      ndarray:           ~118.00ms
      vanilla loop:      ~138.00ms
      mathjs:           ~1876.00ms

    browser
      tfjs webgpu:          ~.16ms
      tfjs webgl:           ~.76ms
      tfjs wasm:           ~2.51ms
      gpu.js:              ~6.00ms
      tfjs cpu:          ~244.65ms
      mathjs:           ~3469.00ms

    c
      accelerate.h:         ~.06ms
Source here: https://github.com/raphaelrk/matrix-mul-test

Re: Making Python fast – Adventures with mypyc

#49

Post by mixmastamyk »

chrisseaton wrote: post #39
mixmastamyk wrote: post #37

Earlier quoted context omitted.

A few things are impossible without changing/subsetting the language. What I was trying to get at.

What things are you thinking of? (Not trying to interrogate you or prove you wrong, but I've got an interest in optimising very difficult meta-programming patterns.)

Nearly everything (or is it everything?) in memory can be modified at runtime. There are no real constants for example. The whole stack top to bottom can be monkeypatched on a whim.

This means nothing is guaranteed and so every instruction must do multiple checks to make sure data structures are what is expected at the current moment.

This is true of JS as well, but to a lesser extent.

Re: Making Python fast – Adventures with mypyc

#50

Post by mkoubaa »

peterkelly wrote: post #11
chrisseaton wrote: post #10

Earlier quoted context omitted.

That's not Node - that's V8. And it's possible to do the same thing for Python - there's nothing magic about JavaScript compared to Python - it's just a lot of engineering work to do it, which is beyond what this project's scope is. PyPy does it, but not inside standard Python.

I'm well aware of V8 and pypy. I also really like Python as a language, especially with mypy. It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API). There is a really important (if…

This is in the process of being addressed - look into the HPy project
Post reply on HN