Live data from Hacker News

Nuitka: An extremely compatible Python compiler

nuitka.net

51–60 of 88 posts

Re: Nuitka: An extremely compatible Python compiler

#51
post #35

Earlier quoted context omitted.

This argument is so tiring. That's part of why websites are so slow despite having insane hardware at their disposal. At my company, for a web app we run in production, we strive to get every response out of our infrastructure in under a millisecond, everything above that except for a few select endpoints is considered as a bug. By using sensible technology choices, it's not even that hard to do. A RDMS like postgres…

Right, I agree. My question is “what application is constrained by interpreter overhead.” It should be faster than milliseconds for almost any code, I would think. I am agreeing with you, I don’t understand your response.

He is pointing out that it isn't necessarily a constraint, just an improvement of the product by using more performant systems.

Re: Nuitka: An extremely compatible Python compiler

#52
Extreme compatibility has a cost.

If you're willing to give up some compatibility, you could get faster code that can be checked statically by transpiling to one of the many great choices from a set of statically typed languages.

This is the approach taken by py14, pyrs and their successor py2many, on which I've been working for some months.

Re: Nuitka: An extremely compatible Python compiler

#55
post #19

Earlier quoted context omitted.

Not really what you are after, but it does use AOT (via generated C++ code). https://arcade.makecode.com/ https://makecode.com/language

> In case of microcontrollers, PXT programs are compiled in the browser to ARM Thumb assembly, and then to machine code, resulting in a file which is then deployed to the microcontroller, usually via USB mass-storage interface. Looks like the only compilation strategy is directly to ARM Thumb assembly or did I miss something?

Maybe my memory is fuzzy about the exact workflow, in any case you can check

"Microsoft MakeCode: from C++ to TypeScript and Blockly (and Back)"

https://www.youtube.com/watch?v=tGhhV2kfJ-w

and the respective C++ FFI,

https://makecode.com/simshim

Re: Nuitka: An extremely compatible Python compiler

#56
post #5

Nuitka looks like a traditional ahead-of-time compiler using SSA form[0] and is written in Python. I’d be interested in seeing performance comparisons with PyPy, which uses the second Futamura protection and is written in a dialect of Python. [0]: https://nuitka.net/doc/developer-manual.html#ssa-form-for-nu...

https://pybenchmarks.org/u64q/benchmark.php?test=all&lang=nu...

"Python Interpreters Benchmarks"

Re: Nuitka: An extremely compatible Python compiler

#57
post #35

Earlier quoted context omitted.

What sort of web applications do you work on where Python interpreter speed is the limiting factor? Usually, those applications are constrained by network throughput and context switches and page faults.

This argument is so tiring. That's part of why websites are so slow despite having insane hardware at their disposal. At my company, for a web app we run in production, we strive to get every response out of our infrastructure in under a millisecond, everything above that except for a few select endpoints is considered as a bug. By using sensible technology choices, it's not even that hard to do. A RDMS like postgres…

What web/app stack are you using to fulfill <1ms responses?

Re: Nuitka: An extremely compatible Python compiler

#58
post #56
post #5

Nuitka looks like a traditional ahead-of-time compiler using SSA form[0] and is written in Python. I’d be interested in seeing performance comparisons with PyPy, which uses the second Futamura protection and is written in a dialect of Python. [0]: https://nuitka.net/doc/developer-manual.html#ssa-form-for-nu...

https://pybenchmarks.org/u64q/benchmark.php?test=all&lang=nu... "Python Interpreters Benchmarks"

Thanks for the link. Don't know if you are affiliated but there is a lot of link rot going on there with external links.

Re: Nuitka: An extremely compatible Python compiler

#59
post #57
post #35

Earlier quoted context omitted.

This argument is so tiring. That's part of why websites are so slow despite having insane hardware at their disposal. At my company, for a web app we run in production, we strive to get every response out of our infrastructure in under a millisecond, everything above that except for a few select endpoints is considered as a bug. By using sensible technology choices, it's not even that hard to do. A RDMS like postgres…

What web/app stack are you using to fulfill <1ms responses?

[deleted]

Re: Nuitka: An extremely compatible Python compiler

#60

Extreme compatibility has a cost. If you're willing to give up some compatibility, you could get faster code that can be checked statically by transpiling to one of the many great choices from a set of statically typed languages. This is the approach taken by py14, pyrs and their successor py2many, on which I've been working for some months.

But it was the lack of 100% compatibility that hampered pypy's adoption.

Anyway what are your incompatibilities?

Post reply on HN