hpy
graalpython
Our great sponsors
hpy | graalpython | |
---|---|---|
20 | 13 | |
1,001 | 1,095 | |
1.9% | 3.0% | |
8.2 | 10.0 | |
22 days ago | 2 days ago | |
Python | Python | |
MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
hpy
-
RustPython
There is a merge request up to add autogen rust bindings to hpy
-
Ruby 3.2’s YJIT is Production-Ready
Are you referencing https://github.com/hpyproject/hpy?
I do hope it takes off.
-
Codon: A high-performance Python compiler
The HPy project [0] seems like a promising way out of this.
-
New record breaking for Python in TechEmPower
socketify.py breaks the record for Python no other Python WebFramework/Server as able to reach 6.2 mi requests per second before in TechEmPower Benchmarks, this puts Python at the same level of performance that Golang, Rust and C++ for web development, in fact Golang got 5.2 mi req/s in this same round. Almost every server or web framework tries to use JIT to boost the performance, but only socketify.py deliveries this level of performance, and even without JIT socketify.py is twice as fast any other web framework/server in active development, and still can be much more optimized using HPy (https://hpyproject.org/). Python will get even faster and faster in future!
-
Is it time to leave Python behind? (My personal rant)
I think Propose a better messaging for Python is the option and a lot of languages will learn it from Rust, because rust erros are the best described errors I see in my life lol. Cargo is amazing and I think we will need a better poetry/pip for sure, HPy project will modernize extensions and packages 📦 too https://hpyproject.org/
-
A Look on Python Web Performance at the end of 2022
It also show that PyPy3 will not magically boost your performance, you need to integrate in a manner that PyPy3 can optimize and delivery CPU performance, with a more complex example maybe it can help more. But why socketify is so much faster using PyPy3? The answer is CFFI, socketify did not use Cython for integration and cannot delivery the full performance on Python3, this will be solved with HPy.
-
socketify.py - Bringing WebSockets, Http/Https High Peformance servers for PyPy3 and Python3
HPy integration to better support CPython, PyPy and GraalPython
-
Your Data Fits in RAM
Absolutely everything in CPython is a PyObject, and that can’t be changed without breaking the C API. A PyObject contains (among other things) a type pointer, a reference count, and a data field; none of these things can be changed without (again) breaking the C API.
There have definitely been attempts to modernize; the HPy project (https://hpyproject.org/), for instance, moves towards a handle-oriented API that keeps implementation details private and thus enables certain optimizations.
-
Python 3.11 is up to 10-60% faster than Python 3.10
NumPy is a sore point (works, but slow) and the missing spark to ignite PyPy adoption for a subset of users. The current hope seems to be HPy. If PyPy acquires good NumPy performance, a lot of people would migrate. Also of note is that conda-forge builds hundreds of packages for PyPy already (I think they started doing that in 2020).
-
The future of Python build systems and Gentoo
I've battled with Python's packaging systems for more than a decade. Every couple of years some new thing comes along promising to fix package management, but it always fails spectacularly on some important, mainstream package or use case. I suspect a lot of this complexity comes down to the significant degree in which the Python ecosystem depends on C: not only do we need to package Python programs but C programs as well, and some people think we should ship C source code and build on the target machine and others think we should ship pre-built C binaries and dynamically link against them on the target machine thus Python supports both mechanisms; however, both are perilous in the general case.
And interestingly, Python depends so hard on C because CPython is very slow, and CPython is very slow because the C-extension API is virtually the whole of the CPython interpreter (many interesting optimizations to the interpreter would break compatibility in the ecosystem). So it certainly feels like all of Python's major problems come down to this decision to lean hard on C and specifically to make so much of the interpreter available for the C-extensions.
The way out as far as I can tell is to define some narrower API surface (e.g., https://hpyproject.org), get the ecosystem to consolidate around that, deprecate the old API surface, and then make the requisite breaking optimizations such that the ecosystem can feasibly do more in native Python. This requires leadership; however, and this has not historically seemed to be Python's strong suite--the Python maintainers seem unable to drive out big, necessary changes like this (which is certainly not to say that leadership is easy, particularly when Python is so established in many respects).
Personally, I've come to use Go for 99% of my Python use cases and it's been great. There are dramatically fewer C bindings, so the build/packaging tooling and performance are orders of magnitude better than in Python. Static typing works well out of the box, real static binaries are not only feasible but trivial (as opposed to Python where you try to build a zip file with your dependencies and the result is hundreds of megabytes and it's still missing the runtime, std libs, and various .so files). Further still, builds, tests, and every kind of tooling are far faster than with Python, and far simpler to install and manage. Unless you're doing data science, I don't think you'll regret the transition.
graalpython
-
socketify.py - Bringing WebSockets, Http/Https High Peformance servers for PyPy3 and Python3
HPy integration to better support CPython, PyPy and GraalPython
-
Oracle Contributing GraalVM Community Edition Java Code to OpenJDK
Here are some nice examples: https://www.graalvm.org/22.2/reference-manual/python/Interop...
This may be more readable: https://github.com/oracle/graalpython/blob/master/docs/user/...
-
Pyjion – A Python JIT Compiler
Isn't this what the GraalVM [1] guys are also trying to do? Seems like today the competition is between who is more polyglot than the other, JVM, CLR or WASM.
- Python stands to lose its GIL, and gain a lot of speed
- A viable solution for Python concurrency
- RustPython: A Python interpreter written in Rust
-
Stack Overflow Developer Survey 2021: "Rust reigns supreme as most loved. Python and Typescript are the languages developers want to work with most if they aren’t already doing so."
Graalpython is slowly taking shape, although it's still very alpha: https://github.com/oracle/graalpython
- Launch HN: Enso (YC S21) – Visual programming and workflow tool for data science
-
AST based scripting languages
https://github.com/oracle/graalpython is an AST interpreter for Python
-
Pyston v2.2: faster and open source
I'd say graal is even less mature than Pyston. See https://github.com/oracle/graalpython/tree/master/docs/user
> At this point, the Python runtime is made available for experimentation and curious end-users.
What are some alternatives?
truffleruby - A high performance implementation of the Ruby programming language, built on GraalVM.
jython - Python for the Java Platform
Pyjion - Pyjion - A JIT for Python based upon CoreCLR
Cython - The most widely used Python to C compiler
nogil - Multithreaded Python without the GIL
cinder - Cinder is Meta's internal performance-oriented production version of CPython.
py2js
RustPython - A Python Interpreter written in Rust
enso - Hybrid visual and textual functional programming.
nqp - NQP