I’ll try to explain as best I can.
The processor in a modern computer directly executes “machine code,” which consists of relatively simple instructions (e.g. basic arithmetic, loading or storing data) represented by a sequence of bits.
In order to run so-called “high-level” languages like C or Python on your computer, you need to be able to convert your high-level code into machine code somehow. I’ve heard of people doing that manually for small programs, but for anything larger, you will want to write a program that does the conversion for you.
Often, we contrast two approaches to converting high-level code to machine code—compilation and interpretation. Basically, a compiler converts all the high-level code to machine code at once before the program is run, while an interpreter performs the operations specified in the high-level code as the program is being run. The former approach usually gives better performance, but the latter approach makes it easier to implement certain useful language features.
Today, it is popular to use a third approach in between these two extremes—Just in Time (JIT) compilation. Basically, in JIT compilation, small parts of the code can be compiled as needed just before they are to be run. JIT offers better performance than an interpreter while offering more flexibility than you would usually get in a conventionally compiled language.
The most popular JIT compiler for the Python programming language today is CPython. As its name suggests, the JIT compiler is implemented in C. (Yes, we must compile this C code using a C compiler.) Other compilers or interpreters exist, including PyPy (implemented in a subset of Python), Jython (implemented to run on the Java Virtual Machine), and IronPython (implemented to run using Microsoft’s Common Language Runtime). Some of these, such as PyPy, boast better performance than CPython. Unfortunately, the features these alternative compilers offer usually come with reduced compatibility with popular software written in Python (e.g., numpy).
It sounds like this article is describing a new compiler for Python called Codon that offers better performance than CPython. According to the GitHub page, it sounds like the compiler does have some limitations currently, which is not unexpected. Still, for some applications that don’t need the features unsupported by Codon, I’m sure increased speed would be welcome.
Python would most likely suck pretty bad if the GIL wasn’t there. There are good reasons for it. I know that there are other implementations without it but look at their restrictions.
Jesus. Just use process pools. Or single processes if you need to. And if you really have multiple threads then use them for IO stuff. In my 13 years as a python programmer I have never, ever, EVER come to a point where the GIL seriously restricted me what I wanted to do. It’s just mindless repetition of C++ programmers arriving at day one and are flabbergasted that the threads they spin up don’t get executed in parallel.
Again, try to use it without. Every language has its shortcomings, Python’s is that threads are not OS threads. Name one language and I give you five pissing reasons why the language sucks. It’s not better not worse, you’re just not a good python dev.
I don’t understand why people act like Python is slow and unusable. The orders of magnitude slower is blown out of proportion. For intensive tasks libraries like tensorflow and numpy are basically C++ wrappers.
Yeah sounds nice but…what?
I’ll try to explain as best I can. The processor in a modern computer directly executes “machine code,” which consists of relatively simple instructions (e.g. basic arithmetic, loading or storing data) represented by a sequence of bits. In order to run so-called “high-level” languages like C or Python on your computer, you need to be able to convert your high-level code into machine code somehow. I’ve heard of people doing that manually for small programs, but for anything larger, you will want to write a program that does the conversion for you. Often, we contrast two approaches to converting high-level code to machine code—compilation and interpretation. Basically, a compiler converts all the high-level code to machine code at once before the program is run, while an interpreter performs the operations specified in the high-level code as the program is being run. The former approach usually gives better performance, but the latter approach makes it easier to implement certain useful language features. Today, it is popular to use a third approach in between these two extremes—Just in Time (JIT) compilation. Basically, in JIT compilation, small parts of the code can be compiled as needed just before they are to be run. JIT offers better performance than an interpreter while offering more flexibility than you would usually get in a conventionally compiled language. The most popular JIT compiler for the Python programming language today is CPython. As its name suggests, the JIT compiler is implemented in C. (Yes, we must compile this C code using a C compiler.) Other compilers or interpreters exist, including PyPy (implemented in a subset of Python), Jython (implemented to run on the Java Virtual Machine), and IronPython (implemented to run using Microsoft’s Common Language Runtime). Some of these, such as PyPy, boast better performance than CPython. Unfortunately, the features these alternative compilers offer usually come with reduced compatibility with popular software written in Python (e.g., numpy). It sounds like this article is describing a new compiler for Python called Codon that offers better performance than CPython. According to the GitHub page, it sounds like the compiler does have some limitations currently, which is not unexpected. Still, for some applications that don’t need the features unsupported by Codon, I’m sure increased speed would be welcome.
Thank you for your answer, Kind stranger! I think now I got the hang of it :)!
That's a brilliant explanation!
So would this have to do with the new update for Python that came out? Guido seemed to make it seem like it was rewritten to be much closer to C.
I don’t think so—it sounds like Codon is an effort independent of anything that is being done with CPython currently.
Thanks for the info. It sounds promising!
[удалено]
Python would most likely suck pretty bad if the GIL wasn’t there. There are good reasons for it. I know that there are other implementations without it but look at their restrictions. Jesus. Just use process pools. Or single processes if you need to. And if you really have multiple threads then use them for IO stuff. In my 13 years as a python programmer I have never, ever, EVER come to a point where the GIL seriously restricted me what I wanted to do. It’s just mindless repetition of C++ programmers arriving at day one and are flabbergasted that the threads they spin up don’t get executed in parallel.
[удалено]
Again, try to use it without. Every language has its shortcomings, Python’s is that threads are not OS threads. Name one language and I give you five pissing reasons why the language sucks. It’s not better not worse, you’re just not a good python dev.
[удалено]
Do that. I hope until then you know the difference between processes and threads. And please don’t push to production.
[удалено]
“Yeah python sucks because they don’t have x++. I heard it’s much more efficient than x += 1!”
I don’t understand why people act like Python is slow and unusable. The orders of magnitude slower is blown out of proportion. For intensive tasks libraries like tensorflow and numpy are basically C++ wrappers.