mypyc
nogil
Our great sponsors
mypyc | nogil | |
---|---|---|
25 | 31 | |
1,667 | 2,853 | |
1.3% | - | |
0.0 | 5.7 | |
about 1 year ago | 2 months ago | |
Python | ||
- | 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.
mypyc
- Making use of type hints
-
Writing Python like it's Rust
That would be interesting! You might already be aware. But there's mypyc[0], which is an AOT compiler for Python code with type hints (that, IIRC, mypy uses to compile itself into a native extension).
Wanted to give you a head-start on the lit-review for your students I guess :)
[0] https://github.com/mypyc/mypyc
-
The different uses of Python type hints
https://github.com/mypyc/mypyc
> Mypyc compiles Python modules to C extensions. It uses standard Python type hints to generate fast code. Mypyc uses mypy to perform type checking and type inference.
> Mypyc can compile anything from one module to an entire codebase. The mypy project has been using mypyc to compile mypy since 2019, giving it a 4x performance boost over regular Python.
I have not experience a 4x boost, rather between 1.5x and 2x. I guess it depends on the code.
-
The Python Paradox
Funny how emergence works with tools. Give a language too few tools but viral circumstances - the ecosystem diverges (Lisps, Javascript). Give it too long an iteration time but killer guarantees, you end up with committees. Python not falling into either of these traps should be understood as nothing short of magic in emergence.
I only recently discovered that python's reference typechecker, mypy, has a small side project for typed python to emit C [1], written entirely in python. Nowadays with python's rich specializer ecosystem (LLVM, CUDA, and just generally vectorized math), the value of writing a small program in anything else diminishes quickly.
Imagine reading the C++wg release notes in the same mood that you would the python release notes.
[1] https://github.com/mypyc/mypyc
-
Codon: A high-performance Python compiler
> Note that the mypyc issue tracker lives in this repository! Please don't file mypyc issues in the mypy issue tracker.
See https://github.com/mypyc/mypyc/blob/master/show_me_the_code....
-
ELI5: Can’t one write a compiler for Python and make everything go brrrr?
And mypyc https://github.com/mypyc/mypyc
-
Is it time for Python to have a statically-typed, compiled, fast superset?
More recent approaches include mypyc which is (on the tin) quite close to what you describe, and taichi that lives in between.
-
Pholyglot version 0.0.0 (PHP to PHP+C polyglot transpiler)
Have you encountered mypyc?
-
Python 3.11 is 25% faster than 3.10 on average
https://github.com/mypyc/mypyc
> Mypyc compiles Python modules to C extensions. It uses standard Python type hints to generate fast code. Mypyc uses mypy to perform type checking and type inference.
-
Comparing implementations of the Monkey language VIII: The Spectacular Interpreted Special (Ruby, Python and Lua)
Regarding the large execution time mentioned in your article, I discovered (mypyc)[https://github.com/mypyc/mypyc] on this subreddit in a post from the black formatter team https://www.reddit.com/r/Python/comments/v2009i/im_that_person_who_got_black_compiled_with_mypyc/?utm_medium=android_app&utm_source=share
nogil
- Proof-of-Concept Multithreaded Python Without the GIL
-
Our Plan for Python 3.13
This might be a dumb question, but why would removing the GIL break FFI? Is it just that existing no-GIL implementations/proposals have discarded/ignored it, or is there a fundamental requirement, e.g. C programs unavoidably interact directly with the GIL? I know that the C-API is only stable between minor releases [0] compiled in the same manner [1], so it's not like the ecosystem is dependent upon it never changing.
I cannot seem to find much discussion about this. I have found a no-GIL interpreter that works with numpy, scikit, etc. [2][3] so it doesn't seem to be a hard limit. (That said, it was not stated if that particular no-GIL implementation requires specially built versions of C-API libs or if it's a drop-in replacement.)
[0]: https://docs.python.org/3/c-api/stable.html#c-api-stability
[1]: https://docs.python.org/3/c-api/stable.html#platform-conside...
[2]: https://github.com/colesbury/nogil
[3]: https://discuss.python.org/t/pep-703-making-the-global-inter...
-
Real Multithreading Is Coming to Python
https://github.com/colesbury/nogil does manage to get rid of the GIL, but it's not certain to make it into Python core. The main problem is the amount of existing libraries that depend on the existence of the GIL without realizing it - breaking those would be extremely disruptive.
-
[D] The hype around Mojo lang
CPython is also investigating the removal of the GIL (PEP703, nogil). I think requiring the GIL is a wider thing that libraries will need to address anyway. But also, for the same reason as above I'd be surprised if the Modular team thought that saying "you can run all your python code unchanged" was a good idea if there was a secret "except for code that uses numpy" muttered under the breath.
- PEP 684 was accepted – Per-interpreter GIL in Python 3.12
- PEP 703 – Making the Global Interpreter Lock Optional in CPython
-
Python 3.11.0 final is now available
I'm worried about the speedup
My understanding is that it's based on the most recent attempt to remove the GIL by Sam Gross
https://github.com/colesbury/nogil
In addition to some ways to try to not have nogil have as much overhead he added a lot of unrelated speed improvements so that python without the gil would still be faster not slower in single thread mode. They seem to have merged those performance patches first that means if they add his Gil removal patches in say python 3.12 it will still be substantially slower then 3.11 although faster then 3.10. I hope that doesn't stop them from removing the gil (at least by default)
- Removed the GIL back in 1996 from Python 1.4, primarily to create a re-entrant Python interpreter.
- I Tried Removing Python's GIL Back in 1996
-
Faster CPython 3.12 Plan
Looks like it's still active to me:
https://github.com/colesbury/nogil/
What are some alternatives?
Cython - The most widely used Python to C compiler
hpy - HPy: a better API for Python
mypy - Optional static typing for Python
numpy - The fundamental package for scientific computing with Python.
beartype - Unbearably fast near-real-time hybrid runtime-static type-checking in pure Python.
Pytorch - Tensors and Dynamic neural networks in Python with strong GPU acceleration
CPython - The Python programming language
python-feedstock - A conda-smithy repository for python.
pex - A tool for generating .pex (Python EXecutable) files, lock files and venvs.
sbcl - Mirror of Steel Bank Common Lisp (SBCL)'s official repository
pyccel - Python extension language using accelerators
cosmopolitan - build-once run-anywhere c library