14 ms·

You can not write a static compiler for python, because python does not have static typing, and it is a dynamic language. So that part is a tautology. I suspec

by ohyes 15y ago

You can not write a static compiler for python, because python does not have static typing, and it is a dynamic language. So that part is a tautology. I suspect the author is trying to say that you can not write a compiler to machine code for python. This is wrong. Compiling dynamic languages to machine code has been done dozens of times in languages with equivalent or greater dynamic properties (Common Lisp, Scheme, and Smalltalk, for example). I guess an example of proof of concept here is that Python was implemented in Common Lisp as a DSL (macros), and it works on the machine code lisp implementations. (http://common-lisp.net/project/clpython/manual.html#compiling-before-running http://common-lisp.net/project/clpython/manual.html#compilin...) The truth is that no one can be bothered to do it, because there is little to be gained from a faster python implementation. All of the slow code is in little parts that can be rewritten in C (or whatever faster language... so almost any language). The mentioned Python compiler projects are all 'research,' as far as I can tell. Doing something that is actually known to work and is difficult would be of no use to someone who is interested in tenure.

rabidsnail 15y ago
I mostly agree with you, but there are cases where the problem isn't that "thing X is too slow", but "after a long period of running the garbage collector gets bogged down with long-lived cycles and dies". So I think garbage collector improvements would be really helpful. Core interpreter improvements, not so much.
- ohyes 15y ago
  Absolutely, improving garbage collection is definitely more interesting/important than code that runs 'faster' for arbitrary benchmarks.
stiff 15y ago
A static compiler has nothing to do with static typing, it is just a traditional compiler that passes through the source code and generates the final result of the compilation in one shot, as opposed to a byte-code JIT compiler. I guess the point is that you can not write an _efficient_ static compiler, because there is too little information available at compile-time. I don't think your examples give a counter-proof here, most Smalltalk compilers are JIT compilers, so it's really an argument in favour of the authors orginal thesis, and Common Lisp introduces a lot of extra type annotations to achieve good compilation results. Racket (PLT Scheme), the most popular Scheme implementation, uses a JIT compiler as well.
- ohyes 15y ago
  My point is that you do not have to go full static compilation to achieve the benefits of using machine code and static compilation techniques. Compiled Common Lisp (without any annotations) is much faster than interpreted python, simply because all of the dynamic dispatch is handled in machine code. To achieve speeds closer to Java and C++ in Common Lisp, you certainly need type annotations (And a working knowledge of the given compiler). But we aren't talking about those speeds, we are talking about maybe a 4x improvement, which could be done. Racket is popular because it is easy to use and has a nice library. There are a number of schemes which are faster than it is.
masklinn 15y ago
> Compiling dynamic languages to machine code has been done dozens of times in languages with equivalent or greater dynamic properties ([...] and Smalltalk, for example) Do you have sources for a static compiler for Smalltalk? Considering how dynamic that language is I have some trouble imagining such a thing. Please note that Alex is not talking about JIT compilers here (for good reason: PyPy has a JIT compiler), but about static compilers. > The truth is that no one can be bothered to do it, because there is little to be gained from a faster python implementation. That's a joke right? A significant part of Pypy's effort is a faster Python implementation. > The mentioned Python compiler projects are all 'research,' as far as I can tell. The only "Python compiler projects" mentioned are ShedSkin and Cython (and both actually compile python-like languages, neither pretends to compiling Python), and neither is a research project, both have purely practical goals (although ShedSkin is completely experimental at this point)
- ohyes 15y ago
  > Do you have sources for a static compiler for Smalltalk > Considering how dynamic that language is I have some trouble imagining such a thing. Smalltalk always uses a virtual machine, it does not always use a JIT. I said a static compiler doesn't make sense for a dynamic language (saying you can't do it is tautological, it is like trying to get dry water). I am talking about dynamic compilation to machine code (Not JIT). From that, you can alter how much code in-lining and optimization happen in nested calls. It is a much used technique and I do not need to prove its validity. Everyone in here seems blind to the possibility, which puzzles me.
  - MostAwesomeDude 15y ago
    JIT is dynamic compilation to machine code. Feel free to explain why your technique is not JIT, though.
    - ohyes 15y ago
      This is not a JIT. http://paste.lisp.org/+2N29 http://paste.lisp.org/+2N29
sqrt17 15y ago
Cython, in my eyes, would qualify as a "production"-level compiler project - the lxml library uses it, and you occasionally run into it in other projects. Cython follows the "optional static typing" approach, and implements a rather large (but not complete) subset of Python. It's a very good intermediate solution for those 20% of the code that take up 80% of the running time.

by ohyes 15y ago

rabidsnail 15y ago

I mostly agree with you, but there are cases where the problem isn't that "thing X is too slow", but "after a long period of running the garbage collector gets bogged down with long-lived cycles and dies". So I think garbage collector improvements would be really helpful. Core interpreter improvements, not so much.

ohyes 15y ago
Absolutely, improving garbage collection is definitely more interesting/important than code that runs 'faster' for arbitrary benchmarks.

stiff 15y ago

A static compiler has nothing to do with static typing, it is just a traditional compiler that passes through the source code and generates the final result of the compilation in one shot, as opposed to a byte-code JIT compiler. I guess the point is that you can not write an _efficient_ static compiler, because there is too little information available at compile-time. I don't think your examples give a counter-proof here, most Smalltalk compilers are JIT compilers, so it's really an argument in favour of the authors orginal thesis, and Common Lisp introduces a lot of extra type annotations to achieve good compilation results. Racket (PLT Scheme), the most popular Scheme implementation, uses a JIT compiler as well.

ohyes 15y ago
My point is that you do not have to go full static compilation to achieve the benefits of using machine code and static compilation techniques. Compiled Common Lisp (without any annotations) is much faster than interpreted python, simply because all of the dynamic dispatch is handled in machine code. To achieve speeds closer to Java and C++ in Common Lisp, you certainly need type annotations (And a working knowledge of the given compiler). But we aren't talking about those speeds, we are talking about maybe a 4x improvement, which could be done. Racket is popular because it is easy to use and has a nice library. There are a number of schemes which are faster than it is.

masklinn 15y ago

> Compiling dynamic languages to machine code has been done dozens of times in languages with equivalent or greater dynamic properties ([...] and Smalltalk, for example) Do you have sources for a static compiler for Smalltalk? Considering how dynamic that language is I have some trouble imagining such a thing. Please note that Alex is not talking about JIT compilers here (for good reason: PyPy has a JIT compiler), but about static compilers. > The truth is that no one can be bothered to do it, because there is little to be gained from a faster python implementation. That's a joke right? A significant part of Pypy's effort is a faster Python implementation. > The mentioned Python compiler projects are all 'research,' as far as I can tell. The only "Python compiler projects" mentioned are ShedSkin and Cython (and both actually compile python-like languages, neither pretends to compiling Python), and neither is a research project, both have purely practical goals (although ShedSkin is completely experimental at this point)

ohyes 15y ago
> Do you have sources for a static compiler for Smalltalk > Considering how dynamic that language is I have some trouble imagining such a thing. Smalltalk always uses a virtual machine, it does not always use a JIT. I said a static compiler doesn't make sense for a dynamic language (saying you can't do it is tautological, it is like trying to get dry water). I am talking about dynamic compilation to machine code (Not JIT). From that, you can alter how much code in-lining and optimization happen in nested calls. It is a much used technique and I do not need to prove its validity. Everyone in here seems blind to the possibility, which puzzles me.
- MostAwesomeDude 15y ago
  JIT is dynamic compilation to machine code. Feel free to explain why your technique is not JIT, though.
  - ohyes 15y ago
    This is not a JIT. http://paste.lisp.org/+2N29 http://paste.lisp.org/+2N29

sqrt17 15y ago

Cython, in my eyes, would qualify as a "production"-level compiler project - the lxml library uses it, and you occasionally run into it in other projects. Cython follows the "optional static typing" approach, and implements a rather large (but not complete) subset of Python. It's a very good intermediate solution for those 20% of the code that take up 80% of the running time.