3 ms·
Let me chip in here to clarify some things. > other languages, just as dynamic, like Common Lisp and Smalltalk, have quite capable JIT compilers. Common Lisp
by heisig 7y ago
Let me chip in here to clarify some things.
> other languages, just as dynamic, like Common Lisp and Smalltalk, have quite capable JIT compilers.
Common Lisp implementations don't need a JIT compiler to be fast. In fact, most of them don't use JIT compilation at all.
What makes Common Lisp implementations (especially SBCL) so fast is a combination of sophisticated static analysis, optional type declarations, and the fact that Common Lisp has been carefully designed to allow for high performance. I cannot stress how important the last point is. The Common Lisp standard is a contract between the programmer and the compiler writer that allows the former to write portable programs, yet gives the latter enough freedom to optimize.
In contrast, the language "standard" of Python doesn't clarify what portable programs may rely on. Instead, programmers tend to rely on the specific behavior of CPython. And reproducing the exact behavior of CPython is much harder than implementing a carefully designed standard.
> So it is a matter of having enough resources to throw at it.
No amount of resources can heal the design decisions of Python. The only way to get Python fast is by going through a painful standardization effort and by breaking some existing code. And I don't see that happening anytime soon. (Python 4 anyone?)
- pjmlp 7y agoFair enough that relying in CPython specific behaviour might be an issue. Although stuff like dictionary ordering, GC implementation, or GIL shouldn't impact JIT implementation. However going back to Smalltalk, which you didn't mention, not only it is as dynamic as Python, at any given moment can the image change its contents, and via messages like becomes: an object completely changes its internal structure.
- scroot 7y ago> not only it is as dynamic as Python, at any given moment can the image change its contents, and via messages like becomes: an object completely changes its internal structure. Another thing: in Smalltalk the idea of a "stack frame" is actually encapsulated in an object called Context, and you can always inspect the current context. It's just an object like everything else in the system. I don't think Python has something like that, but I could be mistaken.
- laurencerowe 7y agoYou can walk and inspect the stack using sys._getframe() forever or the more friendly stack function in the inspect module. * https://docs.python.org/3/library/sys.html#sys._getframe https://docs.python.org/3/library/sys.html#sys._getframe * https://docs.python.org/3/library/inspect.html#the-interpreter-stack https://docs.python.org/3/library/inspect.html#the-interpret...
- lispm 7y agoCommon Lisp can also change the class of a CLOS object. Via CHANGE-CLASS: http://www.lispworks.com/documentation/HyperSpec/Body/f_chg_cl.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_chg_... But these are not the parts where Common Lisp will be fast...
- kazinator 7y agoSmallTalk's become: is a crazy-ass feature which walks the entire graph of reachable objects, and replaces all occurrences of one object with another. A becomes B by virtue of all known references to A being replaced with references to B.
- lispm 7y agoRight, JIT compilers in Common Lisp are mostly not known. There are only a few bytecode interpreters, where it could be used: CLISP, CMU CL with its bytecode interpreter, ... Common Lisp has several execution modes and for compiled code: important are 1) AOT compiled, but fully safe with optional debug info: safety = 3 and debug = 2 2) AOT compiled, but fast and potentially unsafe with little debug infos: speed = 3, safety = 0, debug = 0 The usual goal is to be able to run much of the code in mode 1) and only compile portions in mode 2). Thus much of the language is optimized around possible compilation. The language is very dynamic, but there is also a core, which is not object-oriented - thus potentially easier to compile to fast code. Also incremental in-memory compilation in Common Lisp is AOT and not JIT.