4 ms·

I think Julia has a very bright future. There's no fundamental reason for Python to be so popular in the number crunching sector. I expect a lot of that to migr

I think Julia has a very bright future. There's no fundamental reason for Python to be so popular in the number crunching sector. I expect a lot of that to migrate to Julia over the next decade. Unlike D, I believe it has significant funding.

pjmlp 3y ago
I used to think likewise, until NVidia and Microsoft decided it was about time to make Python implementations actually embrace JITs.
- eigenspace 3y ago
  If all Python needed was a JIT, this would have been addressed over a decade ago. The problem isn't a lack of a compiler, it's language semantics that make the job of a JIT nearly impossible.
  - pjmlp 3y ago
    The usual urban myth, ignoring JIT work in language semantics like Smalltak, Common Lisp, SELF, where anything goes and the whole process space can change in a method call. JIT doesn't happen in Python because the community rather rewrites code in C, than support projects like PyPy. NVidia and Microsoft had to come into play to change this.
    - eigenspace 3y ago
      None of the languages you mention there get even close to C levels of performance when you hit "anything goes" dynamic language features. Those JITs are only competitive (i.e. within an order of magnitude perf) when you are accelerating very barebones code on native types and non-generic functions, or you strip out dynamism. In julia, there is no separation between generic functions and fast functions, and no separation between user defined types and inline allocated structs. This is not the case with Python, Smalltalk, Common Lisp, etc. To actually take hold and stop people from relying on C libraries for everything in Python, the Python JIT is going to have to be as fast as C, and it's also going to need to have a CPython compatible ABI because people are not going to abandon all these pre-existing libraries overnight. Python's semantics make both of those prospects incredibly dubious.
      - pjmlp 3y ago
        So I am lost, are talking about Python JIT compilers or C performance? Smalltalk, Lisp and SELF were used to write complete graphical workstations, where a debugger code change or dynamic code load across the network could impact JIT decisions across the whole OS stack.
        eigenspace 3y ago
        Python JIT compilers don't exist in a vacuum. If you want one to take over, it needs to be worth using. So comparing the performance of that JIT compiler to C performance is very relevant, since the goal has to be to replace code which was written in C with Python code. At the same time though, because Python has such a tremendously big ecosystem, all written in C, and targeting specifically the CPython interpreter ABI, even if you make a JIT compiler that is as fast as C, it'd also need to support the CPython interpreter ABI, otherwise it'd never catch on because the JIT compiled implementation of the language would have to start fresh with almost no ecosystem support. The situation is even worse if we take the realistic view that such a JIT compiler will make some serious performance compromises relative to the existing C code everywhere in the ecosystem, and the fact that the CPython interpreter ABI is so entangled with the internal implementation details that it's impossible to support in a way that's even approaching being performant.
        pjmlp 3y ago
        Which goes back to the point of the community not caring about JITs, which is embodied in the way Python libraries that are thin wrappers around C code, get called as "Python" libraries. They are as much Python as they could be Tcl. Ironically it sufficed to Microsoft and CUDA step in, followed by Facebook as well, Guido gets out of his Python retirement, and JIT, GIL-removal are suddenly issues that matter.
        igouy 3y ago
        > So I am lost Me too. Do you wish to suggest that Smalltalk implementations had "C performance" ? Do you wish to suggest that some Smalltalk programs should still be a little faster than corresponding Ruby +YJIT programs ? (But then NodeJS.) Do you wish to suggest that Ruby +YJIT programs should be faster than corresponding CPython programs ?
  - xioxox 3y ago
    There was a Python JIT a decade ago - Psyco [1]. It was/is a lot faster than normal Python. The community, however, decided to go down the PyPy route. [1] https://en.wikipedia.org/wiki/Psyco https://en.wikipedia.org/wiki/Psyco
    - eigenspace 3y ago
      There's a gigantic graveyard littered with dozens of abanoned Python JITs, Psyco is hardly unique. The community has not at all gone down the PyPy route, nobody uses PyPy either, even if it's technically not abandoned. There's little reason to think these new JITs will fare any better.
- DeathArrow 3y ago
  According to benchmarks, JIT implementations are still very slow.
  - pjmlp 3y ago
    It suffices to be on par with other dynamic languages with a JIT. I am also curious how Mojo will turn out, from the last LLVM developers conference talk, it is quite interesting after all.
- WhereIsTheTruth 3y ago
  Python doesn't need JIT, python's strengths is "it's interpreted", therefore it runs everywhere without having to compile anything in one go, JIT is only useful for servers and long lasting processes, python doesn't fall into that category At best it needs an AOT compiler, to accelerate final scripts, and that's where projects like Mojo start to become interesting

pjmlp 3y ago

I used to think likewise, until NVidia and Microsoft decided it was about time to make Python implementations actually embrace JITs.

eigenspace 3y ago
If all Python needed was a JIT, this would have been addressed over a decade ago. The problem isn't a lack of a compiler, it's language semantics that make the job of a JIT nearly impossible.
- pjmlp 3y ago
  The usual urban myth, ignoring JIT work in language semantics like Smalltak, Common Lisp, SELF, where anything goes and the whole process space can change in a method call. JIT doesn't happen in Python because the community rather rewrites code in C, than support projects like PyPy. NVidia and Microsoft had to come into play to change this.
  - eigenspace 3y ago
    None of the languages you mention there get even close to C levels of performance when you hit "anything goes" dynamic language features. Those JITs are only competitive (i.e. within an order of magnitude perf) when you are accelerating very barebones code on native types and non-generic functions, or you strip out dynamism. In julia, there is no separation between generic functions and fast functions, and no separation between user defined types and inline allocated structs. This is not the case with Python, Smalltalk, Common Lisp, etc. To actually take hold and stop people from relying on C libraries for everything in Python, the Python JIT is going to have to be as fast as C, and it's also going to need to have a CPython compatible ABI because people are not going to abandon all these pre-existing libraries overnight. Python's semantics make both of those prospects incredibly dubious.
    - pjmlp 3y ago
      So I am lost, are talking about Python JIT compilers or C performance? Smalltalk, Lisp and SELF were used to write complete graphical workstations, where a debugger code change or dynamic code load across the network could impact JIT decisions across the whole OS stack.
      - eigenspace 3y ago
        Python JIT compilers don't exist in a vacuum. If you want one to take over, it needs to be worth using. So comparing the performance of that JIT compiler to C performance is very relevant, since the goal has to be to replace code which was written in C with Python code. At the same time though, because Python has such a tremendously big ecosystem, all written in C, and targeting specifically the CPython interpreter ABI, even if you make a JIT compiler that is as fast as C, it'd also need to support the CPython interpreter ABI, otherwise it'd never catch on because the JIT compiled implementation of the language would have to start fresh with almost no ecosystem support. The situation is even worse if we take the realistic view that such a JIT compiler will make some serious performance compromises relative to the existing C code everywhere in the ecosystem, and the fact that the CPython interpreter ABI is so entangled with the internal implementation details that it's impossible to support in a way that's even approaching being performant.
        pjmlp 3y ago
        Which goes back to the point of the community not caring about JITs, which is embodied in the way Python libraries that are thin wrappers around C code, get called as "Python" libraries. They are as much Python as they could be Tcl. Ironically it sufficed to Microsoft and CUDA step in, followed by Facebook as well, Guido gets out of his Python retirement, and JIT, GIL-removal are suddenly issues that matter.
      - igouy 3y ago
        > So I am lost Me too. Do you wish to suggest that Smalltalk implementations had "C performance" ? Do you wish to suggest that some Smalltalk programs should still be a little faster than corresponding Ruby +YJIT programs ? (But then NodeJS.) Do you wish to suggest that Ruby +YJIT programs should be faster than corresponding CPython programs ?
- xioxox 3y ago
  There was a Python JIT a decade ago - Psyco [1]. It was/is a lot faster than normal Python. The community, however, decided to go down the PyPy route. [1] https://en.wikipedia.org/wiki/Psyco https://en.wikipedia.org/wiki/Psyco
  - eigenspace 3y ago
    There's a gigantic graveyard littered with dozens of abanoned Python JITs, Psyco is hardly unique. The community has not at all gone down the PyPy route, nobody uses PyPy either, even if it's technically not abandoned. There's little reason to think these new JITs will fare any better.
DeathArrow 3y ago
According to benchmarks, JIT implementations are still very slow.
- pjmlp 3y ago
  It suffices to be on par with other dynamic languages with a JIT. I am also curious how Mojo will turn out, from the last LLVM developers conference talk, it is quite interesting after all.
WhereIsTheTruth 3y ago
Python doesn't need JIT, python's strengths is "it's interpreted", therefore it runs everywhere without having to compile anything in one go, JIT is only useful for servers and long lasting processes, python doesn't fall into that category At best it needs an AOT compiler, to accelerate final scripts, and that's where projects like Mojo start to become interesting