9 ms·

Writing Python Extensions in Assembly

98 points by ofou 5y ago

question000 5y ago
When you can easily drop down to low-levels and write code in C or even Assembly in Python, why bother using any other language? I'm pretty confident at this point that Python is just going to eclipse anything else, I've been programming for years now and aside from using JS in browser I find it baffling that people would use anything but Python or C.
deleted 5y ago
[deleted]
TekMol 5y ago
Something has to happen regarding Python performance. What could it be? Can CPython become faster? Could the devs take a look at how PHP and Javascript did it to make their runtimes so fast? Can the Python language get extended so that you can define the bottlencks of your code in another language? Maybe in C? PHP? Javascript? Webassembly? Python bytecode? Can a new runtime take over and everybody settle on it? Which one could it be?
- tekknolagi 5y ago
  [disclaimer: I have contributed to a couple different Python runtimes and employed to work on Cinder] > Can CPython become faster? Yes. There are several people (including a team by Guido and Mark Shannon) working on making CPython faster in-tree. There are others, including the folks on Cinder and Pyjion, who are working on extensions to CPython out of tree. > Could the devs take a look [...] It's no secret how they made their runtimes fast. It's all -- more or less -- implementations of the original Smalltalk-80 paper and all that fell out of it. > Can the Python language get extended so that you can define the bottlencks of your code in another language? C extensions are already available in Python, and have been for quite some time. In fact, I would argue they are a little bit part of the problem: there are so many C extensions that runtime optimization efforts don't have as much effect as people would like; the slow stuff is already in C. > Can a new runtime take over and everybody settle on it? There are a lot of "competing" Python runtimes that serve different use-cases. Some use PyPy. Some use Jython. Some use Cinder. etc. Though everyone seems to ask "why not just use PyPy?", people forget to consider that everyone has different constraints that PyPy does not necessarily satisfy.
  - andi999 5y ago
    Could you elaborate on the original smalltalk paper and its relation to js jit?
    - KMag 5y ago
      McCarthy is generally credited with the first JIT for his early LISP work, but SmallTalk and SmallTalk-inspired languages were involved in a lot of the pioneering work related to modern JITs. My understanding is that McCarthy's JIT generated machine code as source code was first loaded, not when it was first invoked. As far as I know, the earliest VMs to wait until a function's first invocation to JIT the function were SmallTalk VMs. The Self language by David Ungar and others was an expansion of some of the SmallTalk ideas. If I remember correctly, Self is where polymorphic inline caching originated. Sun acqui-hired Urs Holzle (who did his PhD under Ungar), David Griswald, Gilad Bracha, and Lars Bak for their StrongTalk (statically typed dialect of SmallTalk) hybrid bytecode interpreter/JIT, which was the basis for the HotSpot JVM. Lars Bak later created the original V8 JavaScript JIT for Chrome. When I was on the Google web search indexing team, I did a bit of work running a pre-release V8 in the indexing pipeline (to analyze text and formatting changes made to pages by JavaScript). If I remember correctly, at that time V8 wasn't a hybrid interpreter/JIT, but did quick-and-dirty generation of x86 machine code when a function was first invoked, and leaned heavily on polymorphic inline caching. My understanding is that early V8 was rather similar to the Self VM. I believe ideas like tracing JITs originated a bit further from the SmallTalk ecosystem, but a lot of modern JIT ideas and techniques came from early SmallTalk and related research.
      - pjmlp 5y ago
        Since you mention McCarthy and JITs, there is another set of poor folks that seem forgoten on JIT research. Only recently did I learn that Dartmouth BASIC did use a JIT approach as well. It was only when dialects started to crop up on 8-bit computers that the trend for BASIC to be an interpreted language came to be.
      - rjsw 5y ago
        I don't remember any Lisp work being considered an example of a JIT, the Deutsch/Schiffman paper was felt to be a big breakthrough when it was published.
- haberman 5y ago
  Python is difficult to optimize due to complex language semantics. This excellent talk describes how the semantics of the "add" operation are much more complex than generally described. a+b is not just a.__add__(b), you have to read 200+ lines of CPython interpreter code to fully resolve its semantics: https://youtu.be/qCGofLIzX6g https://youtu.be/qCGofLIzX6g Not saying it's impossible, but it's more of an uphill battle than optimizing other languages that have more regular semantics. Python is also constrained by its C API, which is a very low-level and exposes a lot of implementation details to C extensions. Changing the API could improve performance but it would also make Python incompatible with a large ecosystem of C extensions. I sometimes wish for Python to define a new C API that exposes far less, and to begin a long-term migration towards the new API so that eventually the interpreter would be less constrained. It would be a large migration, but unlike Python 2 -> 3 it wouldn't affect everyday users, only extension authors. I don't know if it will ever happen, but a person can dream.
  - tekknolagi 5y ago
    Check out HPy.
MrYellowP 5y ago
Nice. I used to just call compiled assembly code from python directly, using fasm.dll. No extensions required. Seems like a rather unnecessary step.
traverseda 5y ago
What I really want is just for the core of popular python interpreters (CPython, pypy) to support MicroPython's native or viper code emitters. https://docs.micropython.org/en/v1.9.3/pyboard/reference/speed_python.html#the-native-code-emitter https://docs.micropython.org/en/v1.9.3/pyboard/reference/spe... There are plenty of solutions for this, but having a standard that works cleanly across all kinds of python interpreters would be really good. Maybe someone can make the viper code emitter into a PEP?

98 points by ofou 5y ago

When you can easily drop down to low-levels and write code in C or even Assembly in Python, why bother using any other language? I'm pretty confident at this point that Python is just going to eclipse anything else, I've been programming for years now and aside from using JS in browser I find it baffling that people would use anything but Python or C.

deleted 5y ago

[deleted]

TekMol 5y ago

Something has to happen regarding Python performance. What could it be? Can CPython become faster? Could the devs take a look at how PHP and Javascript did it to make their runtimes so fast? Can the Python language get extended so that you can define the bottlencks of your code in another language? Maybe in C? PHP? Javascript? Webassembly? Python bytecode? Can a new runtime take over and everybody settle on it? Which one could it be?

tekknolagi 5y ago
[disclaimer: I have contributed to a couple different Python runtimes and employed to work on Cinder] > Can CPython become faster? Yes. There are several people (including a team by Guido and Mark Shannon) working on making CPython faster in-tree. There are others, including the folks on Cinder and Pyjion, who are working on extensions to CPython out of tree. > Could the devs take a look [...] It's no secret how they made their runtimes fast. It's all -- more or less -- implementations of the original Smalltalk-80 paper and all that fell out of it. > Can the Python language get extended so that you can define the bottlencks of your code in another language? C extensions are already available in Python, and have been for quite some time. In fact, I would argue they are a little bit part of the problem: there are so many C extensions that runtime optimization efforts don't have as much effect as people would like; the slow stuff is already in C. > Can a new runtime take over and everybody settle on it? There are a lot of "competing" Python runtimes that serve different use-cases. Some use PyPy. Some use Jython. Some use Cinder. etc. Though everyone seems to ask "why not just use PyPy?", people forget to consider that everyone has different constraints that PyPy does not necessarily satisfy.
- andi999 5y ago
  Could you elaborate on the original smalltalk paper and its relation to js jit?
  - KMag 5y ago
    McCarthy is generally credited with the first JIT for his early LISP work, but SmallTalk and SmallTalk-inspired languages were involved in a lot of the pioneering work related to modern JITs. My understanding is that McCarthy's JIT generated machine code as source code was first loaded, not when it was first invoked. As far as I know, the earliest VMs to wait until a function's first invocation to JIT the function were SmallTalk VMs. The Self language by David Ungar and others was an expansion of some of the SmallTalk ideas. If I remember correctly, Self is where polymorphic inline caching originated. Sun acqui-hired Urs Holzle (who did his PhD under Ungar), David Griswald, Gilad Bracha, and Lars Bak for their StrongTalk (statically typed dialect of SmallTalk) hybrid bytecode interpreter/JIT, which was the basis for the HotSpot JVM. Lars Bak later created the original V8 JavaScript JIT for Chrome. When I was on the Google web search indexing team, I did a bit of work running a pre-release V8 in the indexing pipeline (to analyze text and formatting changes made to pages by JavaScript). If I remember correctly, at that time V8 wasn't a hybrid interpreter/JIT, but did quick-and-dirty generation of x86 machine code when a function was first invoked, and leaned heavily on polymorphic inline caching. My understanding is that early V8 was rather similar to the Self VM. I believe ideas like tracing JITs originated a bit further from the SmallTalk ecosystem, but a lot of modern JIT ideas and techniques came from early SmallTalk and related research.
    - pjmlp 5y ago
      Since you mention McCarthy and JITs, there is another set of poor folks that seem forgoten on JIT research. Only recently did I learn that Dartmouth BASIC did use a JIT approach as well. It was only when dialects started to crop up on 8-bit computers that the trend for BASIC to be an interpreted language came to be.
    - rjsw 5y ago
      I don't remember any Lisp work being considered an example of a JIT, the Deutsch/Schiffman paper was felt to be a big breakthrough when it was published.
haberman 5y ago
Python is difficult to optimize due to complex language semantics. This excellent talk describes how the semantics of the "add" operation are much more complex than generally described. a+b is not just a.__add__(b), you have to read 200+ lines of CPython interpreter code to fully resolve its semantics: https://youtu.be/qCGofLIzX6g https://youtu.be/qCGofLIzX6g Not saying it's impossible, but it's more of an uphill battle than optimizing other languages that have more regular semantics. Python is also constrained by its C API, which is a very low-level and exposes a lot of implementation details to C extensions. Changing the API could improve performance but it would also make Python incompatible with a large ecosystem of C extensions. I sometimes wish for Python to define a new C API that exposes far less, and to begin a long-term migration towards the new API so that eventually the interpreter would be less constrained. It would be a large migration, but unlike Python 2 -> 3 it wouldn't affect everyday users, only extension authors. I don't know if it will ever happen, but a person can dream.
- tekknolagi 5y ago
  Check out HPy.

MrYellowP 5y ago

Nice. I used to just call compiled assembly code from python directly, using fasm.dll. No extensions required. Seems like a rather unnecessary step.

traverseda 5y ago

What I really want is just for the core of popular python interpreters (CPython, pypy) to support MicroPython's native or viper code emitters. https://docs.micropython.org/en/v1.9.3/pyboard/reference/speed_python.html#the-native-code-emitter https://docs.micropython.org/en/v1.9.3/pyboard/reference/spe... There are plenty of solutions for this, but having a standard that works cleanly across all kinds of python interpreters would be really good. Maybe someone can make the viper code emitter into a PEP?