4 ms·

I was active in the Python community in the 200x timeframe, and I daresay the common consensus is that language didn't matter and a sufficiently smart compiler/

by jerf 1y ago

I was active in the Python community in the 200x timeframe, and I daresay the common consensus is that language didn't matter and a sufficiently smart compiler/JIT/whatever would eventually make dynamic scripting languages as fast as C, so there was no reason to learn static languages rather than just waiting for this to happen. It was not universal. But it was very common and at least plausibly a majority view, so this idea wasn't just some tiny minority view either. I consider this idea falsified now, pending someone actually coming up with a JIT/compiler/whatever that achieves this goal. We've poured millions upon millions of dollars into the task and the scripting languages still are not as fast as C or static languages in general. These millions were not wasted; there were real speedups worth having, even if they are somewhat hard on RAM. But they have clearly plateaued well below "C speed" and there is currently no realistic chance of that happening anytime soon. Some people still have not noticed that the idea has been falsified and I even occasionally run into someone who thinks Javascript actually is as fast as C in general usage. But it's not and it's not going to be.

yxhuvud 1y ago
While what you say is true, there is still a huge gap between the performance of javascript (and even Ruby) and that of Python. The efforts to optimize Python are lagging behind, so there is a lot of things that still can be made faster.
- Sesse__ 1y ago
  Python is also choosing to play with one hand behind its back; e.g., the “no extension API changes” rule which means any hope of a faster value representation (one of the most important factors in making a dynamic language fast!) goes out the window, refusing to change the iterator API (which means that throwing and handling exceptions is something that needs to be handled by the fast path of basically everything), and so on.
  - pbronez 1y ago
    Those changes are big enough that they’d need to be a Python 4, don’t you think? Community is still gun why after the 2-3 transition pain.
    - adgjlsfhk1 1y ago
      yeah. Python is somewhat trapped here. because Python is slow, real work gets moved to C, and the C api makes it almost impossible to speed Python up. If Python had made the API changes needed for speed 20 years ago, there would be way less C code, so further changes would be easier, but that ship has now basically sailed
      - gpderetta 1y ago
        It could have made the changes in the 2->3 transition. Instead we got parentheses around print.
    - Sesse__ 1y ago
      The biggest problem of the Python 3 release was that it broke a bunch of _Python_ code. That's pretty different from changing the C API. But sure, it has ups and it has downs. One of the downs is that Python, despite a lot of announcements over the years, still is struggling to become significantly faster.
- School-Cotton 1y ago
  Google has been pouring huge amounts of effort into making their JS interpreter fast for many years at this point. They have a lot more resources than the Python foundation.
  - azhenley 1y ago
    Microsoft had the Faster CPython team for several years, and then recently laid off some of the core devs and the team lead.
  - no_wizard 1y ago
    At one point, Google was also interested in pouring lots of money into making Python faster, and they shifted those resources away. I think what always ends up failing here is that, as others have stated, they won't make breaking API changes, in particular those in charge of driving Python forward are extremely hesitant to break the C API for fear of losing packages that have make Python so popular. I would imagine, if the leadership was willing to put in the elbow grease to help those key packages along the changes when they happen, they could do it, but I understand that its not always that simple
  - dehrmann 1y ago
    Meta does some work for this with Cinder, but Meta has a history of language forks, and it's far enough off the beaten track that I wouldn't use it.
    - zem 1y ago
      cinder team member here - we are putting a lot of work into having cinder converge with rather than diverge from mainline cpython. the main idea is to get support for pluggable JITs into cpython, and then have cinder use those APIs to work as a regular extension module.
amval 1y ago
> I was active in the Python community in the 200x timeframe, and I daresay the common consensus is that language didn't matter and a sufficiently smart compiler/JIT/whatever would eventually make dynamic scripting languages as fast as C, so there was no reason to learn static languages rather than just waiting for this to happen. To be very pedantic, the problem is not that these are dynamic languages _per se_, but that they were designed with semantics unconcerned with performance. As such, retrofitting performance can be extremely challenging. As a counterexample of fast and dynamic: https://julialang.org/ https://julialang.org/ (of course, you pay the prize in other places) I agree with your comment overall, though.
- throw10920 1y ago
  What are examples of those semantics? I'm guessing rebindable functions (and a single function/variable namespace), eval(), and object members available as a dict.
  - hmry 1y ago
    Some examples that come to mind: You can inspect the call stack, and get a list of local variables of your callers. You can assign to object.__class__ to dynamically change an existing object's class at runtime. You can overwrite every operator, including obj.field access, dynamically at runtime (including changing an existing class)
    - homarp 1y ago
      a long time ago, there was Parrot and a bet with Guido https://justatheory.com/2004/08/oscon-notes/ https://justatheory.com/2004/08/oscon-notes/
- jerf 1y ago
  I'm sort of surprised I'm not seeing any modernized dynamic scripting languages coming out lately, despite the general trend towards static languages. A fast dynamic language, with a day-one concurrency story, and some other key feature that pushes it ahead seems possible to me. (I dunno, maybe a nice story for binding to Rust instead of binding to C at this point could be enough to lift a language off?) I don't see any reason why dynamic scripting languages as a category couldn't do that. The ones we have now don't, not because the category makes it impossible, but because by the time that was desirable they just had too much baggage, and are all still struggling with it even a decade after they started.
morkalork 1y ago
I remember this from the early 2010s "compilation of a dynamic language is a superset of compilation of static languages ergo we should be able to achieve both optimizations static languages can do and more because there are opportunities that only become apparent at runtime". When really its all about the constraints you can put on the user that set you up for better optimization.
- senkora 1y ago
  And profile-guided optimization (PGO) for static languages turned out to be pretty good at revealing those “only apparent at runtime” optimizations.
- dehrmann 1y ago
  That's like the joke that dynamic languages are static languages, but with only one type: hash table.
  - gugagore 1y ago
    That's not a joke. It's a perspective that is seriously held: https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ https://existentialtype.wordpress.com/2011/03/19/dynamic-lan... (Not everyone agrees, for sure, but that's different from it being a joke.)
PaulHoule 1y ago
Javascript and Common Lisp aren't as fast as C but they are faster than Python.
- eigenspace 1y ago
  Javascript and common lisp don't have object models that are as anathema to optimization as python does. Well, CLOS is pretty bad, but at least the badness is typically isolated.
beebmam 1y ago
I don’t understand the sentiment of not wanting to learn a language. LLMs make learning and understanding trivial if the user wants that. I think many of those complaining about strongly typed languages (etc) are lazy. In this new world of AI generated code, strongly typed languages are king
sevensor 1y ago
Python is definitely slower for programs that do the same thing. What I see is that the users of fast languages often write programs that do the wrong thing, 30x faster than Python. No free lunch either way
emtel 1y ago
This is all true, but there's another angle that often gets missed: JITs are really only ideal for request-processing systems, in which a) memory is abundant b) the same code paths run over and over and over again, and c) good p99 latency is usually the bar. In contrast, in user facing apps, you usually find that a) memory is constrained b) lots of code runs rarely or in some cases once (e.g. the whole start-up path) c) what would be considered good p99 latency for a server can translate to pretty bad levels of jank. JITs can't do anything if the code you care about runs rarely and causes a frame skip every time you hit it, either because the JIT hasn't triggered yet due to too-few samples, or the generated code has been evicted from the JIT cache because you don't have memory to spare. And if you have code that needs to run fast _every_ time it runs, the easiest way to do that is to start with fast code already compiled and ready to execute. We saw this play out when android moved from Dalvik (JIT) to ART (AoT compilation). Apple figured this out years earlier. Of course it's not that there are no highly performant apps built on JIT runtimes. But it's a significant headwind. (Most of the above applies equally to tracing GC, btw)
- pjmlp 1y ago
  You missed the part where Android moved into caching JIT code with a mix AOT mode compilation, since Android 7 thus avoiding those issues. Latest version is Android 16, many other optimization happened since then. Also that Android followed up on Windows Phone model, their mistake was making the AOT compilation on the phone instead of on the store like Windows Phone was doing. JITs are very capable, provided people also design with them in mind. The clever Apple with AOT failed against this now famous benchmark, against tracing GC languages, using a JIT. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages

by jerf 1y ago

yxhuvud 1y ago

While what you say is true, there is still a huge gap between the performance of javascript (and even Ruby) and that of Python. The efforts to optimize Python are lagging behind, so there is a lot of things that still can be made faster.

Sesse__ 1y ago
Python is also choosing to play with one hand behind its back; e.g., the “no extension API changes” rule which means any hope of a faster value representation (one of the most important factors in making a dynamic language fast!) goes out the window, refusing to change the iterator API (which means that throwing and handling exceptions is something that needs to be handled by the fast path of basically everything), and so on.
- pbronez 1y ago
  Those changes are big enough that they’d need to be a Python 4, don’t you think? Community is still gun why after the 2-3 transition pain.
  - adgjlsfhk1 1y ago
    yeah. Python is somewhat trapped here. because Python is slow, real work gets moved to C, and the C api makes it almost impossible to speed Python up. If Python had made the API changes needed for speed 20 years ago, there would be way less C code, so further changes would be easier, but that ship has now basically sailed
    - gpderetta 1y ago
      It could have made the changes in the 2->3 transition. Instead we got parentheses around print.
  - Sesse__ 1y ago
    The biggest problem of the Python 3 release was that it broke a bunch of _Python_ code. That's pretty different from changing the C API. But sure, it has ups and it has downs. One of the downs is that Python, despite a lot of announcements over the years, still is struggling to become significantly faster.
School-Cotton 1y ago
Google has been pouring huge amounts of effort into making their JS interpreter fast for many years at this point. They have a lot more resources than the Python foundation.
- azhenley 1y ago
  Microsoft had the Faster CPython team for several years, and then recently laid off some of the core devs and the team lead.
- no_wizard 1y ago
  At one point, Google was also interested in pouring lots of money into making Python faster, and they shifted those resources away. I think what always ends up failing here is that, as others have stated, they won't make breaking API changes, in particular those in charge of driving Python forward are extremely hesitant to break the C API for fear of losing packages that have make Python so popular. I would imagine, if the leadership was willing to put in the elbow grease to help those key packages along the changes when they happen, they could do it, but I understand that its not always that simple
- dehrmann 1y ago
  Meta does some work for this with Cinder, but Meta has a history of language forks, and it's far enough off the beaten track that I wouldn't use it.
  - zem 1y ago
    cinder team member here - we are putting a lot of work into having cinder converge with rather than diverge from mainline cpython. the main idea is to get support for pluggable JITs into cpython, and then have cinder use those APIs to work as a regular extension module.

amval 1y ago

> I was active in the Python community in the 200x timeframe, and I daresay the common consensus is that language didn't matter and a sufficiently smart compiler/JIT/whatever would eventually make dynamic scripting languages as fast as C, so there was no reason to learn static languages rather than just waiting for this to happen. To be very pedantic, the problem is not that these are dynamic languages _per se_, but that they were designed with semantics unconcerned with performance. As such, retrofitting performance can be extremely challenging. As a counterexample of fast and dynamic: https://julialang.org/ https://julialang.org/ (of course, you pay the prize in other places) I agree with your comment overall, though.

throw10920 1y ago
What are examples of those semantics? I'm guessing rebindable functions (and a single function/variable namespace), eval(), and object members available as a dict.
- hmry 1y ago
  Some examples that come to mind: You can inspect the call stack, and get a list of local variables of your callers. You can assign to object.__class__ to dynamically change an existing object's class at runtime. You can overwrite every operator, including obj.field access, dynamically at runtime (including changing an existing class)
  - homarp 1y ago
    a long time ago, there was Parrot and a bet with Guido https://justatheory.com/2004/08/oscon-notes/ https://justatheory.com/2004/08/oscon-notes/
jerf 1y ago
I'm sort of surprised I'm not seeing any modernized dynamic scripting languages coming out lately, despite the general trend towards static languages. A fast dynamic language, with a day-one concurrency story, and some other key feature that pushes it ahead seems possible to me. (I dunno, maybe a nice story for binding to Rust instead of binding to C at this point could be enough to lift a language off?) I don't see any reason why dynamic scripting languages as a category couldn't do that. The ones we have now don't, not because the category makes it impossible, but because by the time that was desirable they just had too much baggage, and are all still struggling with it even a decade after they started.

morkalork 1y ago

I remember this from the early 2010s "compilation of a dynamic language is a superset of compilation of static languages ergo we should be able to achieve both optimizations static languages can do and more because there are opportunities that only become apparent at runtime". When really its all about the constraints you can put on the user that set you up for better optimization.

senkora 1y ago
And profile-guided optimization (PGO) for static languages turned out to be pretty good at revealing those “only apparent at runtime” optimizations.
dehrmann 1y ago
That's like the joke that dynamic languages are static languages, but with only one type: hash table.
- gugagore 1y ago
  That's not a joke. It's a perspective that is seriously held: https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ https://existentialtype.wordpress.com/2011/03/19/dynamic-lan... (Not everyone agrees, for sure, but that's different from it being a joke.)

PaulHoule 1y ago

Javascript and Common Lisp aren't as fast as C but they are faster than Python.

eigenspace 1y ago
Javascript and common lisp don't have object models that are as anathema to optimization as python does. Well, CLOS is pretty bad, but at least the badness is typically isolated.

beebmam 1y ago

I don’t understand the sentiment of not wanting to learn a language. LLMs make learning and understanding trivial if the user wants that. I think many of those complaining about strongly typed languages (etc) are lazy. In this new world of AI generated code, strongly typed languages are king

sevensor 1y ago

Python is definitely slower for programs that do the same thing. What I see is that the users of fast languages often write programs that do the wrong thing, 30x faster than Python. No free lunch either way

emtel 1y ago

This is all true, but there's another angle that often gets missed: JITs are really only ideal for request-processing systems, in which a) memory is abundant b) the same code paths run over and over and over again, and c) good p99 latency is usually the bar. In contrast, in user facing apps, you usually find that a) memory is constrained b) lots of code runs rarely or in some cases once (e.g. the whole start-up path) c) what would be considered good p99 latency for a server can translate to pretty bad levels of jank. JITs can't do anything if the code you care about runs rarely and causes a frame skip every time you hit it, either because the JIT hasn't triggered yet due to too-few samples, or the generated code has been evicted from the JIT cache because you don't have memory to spare. And if you have code that needs to run fast _every_ time it runs, the easiest way to do that is to start with fast code already compiled and ready to execute. We saw this play out when android moved from Dalvik (JIT) to ART (AoT compilation). Apple figured this out years earlier. Of course it's not that there are no highly performant apps built on JIT runtimes. But it's a significant headwind. (Most of the above applies equally to tracing GC, btw)

pjmlp 1y ago
You missed the part where Android moved into caching JIT code with a mix AOT mode compilation, since Android 7 thus avoiding those issues. Latest version is Android 16, many other optimization happened since then. Also that Android followed up on Windows Phone model, their mistake was making the AOT compilation on the phone instead of on the store like Windows Phone was doing. JITs are very capable, provided people also design with them in mind. The clever Apple with AOT failed against this now famous benchmark, against tracing GC languages, using a JIT. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages