6 ms·

Honestly, 2-9% already seems like a very signficant improvement, especially since as they mention "remember that CPython is already written in C". Whilst it's g

by Topfi 3y ago

Honestly, 2-9% already seems like a very signficant improvement, especially since as they mention "remember that CPython is already written in C". Whilst it's great to look at the potential for even greater gains by building upon this work, I feel we shouldn't undersell what's been accomplished.

adastra22 3y ago
What is being accomplished then?
- gray_-_wolf 3y ago
  2-9%
bomewish 3y ago
Also recall that a 50% speed improvement in SQLite was caused by 50-100 different optimisations that each eeked out 0.5-1% speedups. On phone now don’t have the ref but it all adds up.
- boxed 3y ago
  Many small improvements is the way to go in most situations. It's not great clickbait, but we should remember that we got from a single cell at some time to humans through many small changes. The world would be a lot better if people just embraced the grind of many small improvements...
- toyg 3y ago
  Marginal gains. https://www.bbc.co.uk/news/magazine-34247629 https://www.bbc.co.uk/news/magazine-34247629
- Akronymus 3y ago
  I tried searching for that article because I vaguely recall it, but can't find it either. But yeah, a lot of small improvements add up. Reminds me of this talk: https://www.youtube.com/watch?v=NZ5Lwzrdoe8 https://www.youtube.com/watch?v=NZ5Lwzrdoe8
  - Topfi 3y ago
    Here is a source for the SQLite case: https://topic.alibabacloud.com/a/sqlite-387-a-large-number-of-minor-optimizations-improving-performance-by-more-than-50_1_46_32753417.html https://topic.alibabacloud.com/a/sqlite-387-a-large-number-o...
    - Akronymus 3y ago
      That looks like blogspam to me, rather than an actual source.
    - formerly_proven 3y ago
      https://sqlite-users.sqlite.narkive.com/CVRvSKBs/50-faster-than-3-7-17# https://sqlite-users.sqlite.narkive.com/CVRvSKBs/50-faster-t...
- IshKebab 3y ago
  That's true, and Rust compiler speed has seen similar speedups from lots of 1% improvements. But even if you can get a 2x improvement from lots of 1% improvements (if you work really really hard), you're never going to get a 10x improvement. Rust is never going to compile remotely as quickly as Go. Python is never going to be remotely as fast as Rust, C++, Go, Java, C#, Dart, etc.
  - inglor_cz 3y ago
    Does it matter? Trains are never going to beat jets in pure speed. But in certain scenarios, trains make a lot more sense to use than jets, and in those scenarios, it is usually preferable having a 150 mph train to a 75 mph train. Looking at the world of railways, high-speed rail has attracted a lot more paying customers than legacy railways, even though it doesn't even try to achieve flight-like speeds. Same with programming languages, I guess.
    - fl0ki 3y ago
      What is the programming analogy here? Two decades ago, you could (as e.g. Paul Graham did at the time) argue that dynamically typed languages can get your ideas to market faster so you become viable and figure out optimization later. It's been a long time since that argument held. Almost every dynamic programming language still under active development is adding some form of gradual typing because the maintainability benefits alone are clearly recognized, though such languages still struggle to optimize well. Now there are several statically typed languages to choose from that get those maintainability benefits up-front and optimize very well. Different languages can still be a better fit for different projects, e.g. Rust, Go, and Swift are all statically typed compiled languages better fit for different purposes, but in your analogy they're all jets designed for different tactical roles, none of them are "trains" of any speed. Analogies about how different programming languages are like different vehicles or power tools or etc go way back and have their place, but they have to recognize that sometimes one design approach largely supersedes another for practical purposes. Maybe the analogy would be clearer comparing jets and trains which each have their place, to horse-drawn carriages which still exist but are virtually never chosen for their functional benefits.
spacechild1 3y ago
> "remember that CPython is already written in C" What is this supposed to say? Most scripting language interpreters are written in low level languages (or assembly), but that alone doesn't say anything about the performance of the language itself.
- nertirs 3y ago
  This means, that a lot of python libraries like polars or tensorflow are written not in python. So python programs, that already spend most of its cpu time running these libraries code, won't see much of an impact.
  - gh02t 3y ago
    Isn't the point that if pure Python was faster they wouldn't need to be written in other [compiled] languages? Having dealt with Cython it's not bad, but if I could write more of my code in native Python my development experience would be a lot simpler. Granted we're still very far from that and probably won't ever reach it, but there definitely seems to be a lot of progress.
    - __MatrixMan__ 3y ago
      Since Nim compiles to C, a middle step worth being aware of is Nim + nimporter which isn't anywhere near "just python" but is (maybe?) closer than "compile a C binary and call it from python". Or maybe it's just syntactic sugar around that. But sugar can be nice.
- eequah9L 3y ago
  I think they mean that a lot of runtime of any benchmark is going to be spent in the C bits of the standard library, and therefore not subject to the JIT. Only the glue code and the bookkeeping or whatnot that the benchmark introduces would be improved by the JIT. This reduces the impact that the JIT can make.

by Topfi 3y ago

adastra22 3y ago

What is being accomplished then?

gray_-_wolf 3y ago
2-9%

bomewish 3y ago

Also recall that a 50% speed improvement in SQLite was caused by 50-100 different optimisations that each eeked out 0.5-1% speedups. On phone now don’t have the ref but it all adds up.

boxed 3y ago
Many small improvements is the way to go in most situations. It's not great clickbait, but we should remember that we got from a single cell at some time to humans through many small changes. The world would be a lot better if people just embraced the grind of many small improvements...
toyg 3y ago
Marginal gains. https://www.bbc.co.uk/news/magazine-34247629 https://www.bbc.co.uk/news/magazine-34247629
Akronymus 3y ago
I tried searching for that article because I vaguely recall it, but can't find it either. But yeah, a lot of small improvements add up. Reminds me of this talk: https://www.youtube.com/watch?v=NZ5Lwzrdoe8 https://www.youtube.com/watch?v=NZ5Lwzrdoe8
- Topfi 3y ago
  Here is a source for the SQLite case: https://topic.alibabacloud.com/a/sqlite-387-a-large-number-of-minor-optimizations-improving-performance-by-more-than-50_1_46_32753417.html https://topic.alibabacloud.com/a/sqlite-387-a-large-number-o...
  - Akronymus 3y ago
    That looks like blogspam to me, rather than an actual source.
  - formerly_proven 3y ago
    https://sqlite-users.sqlite.narkive.com/CVRvSKBs/50-faster-than-3-7-17# https://sqlite-users.sqlite.narkive.com/CVRvSKBs/50-faster-t...
IshKebab 3y ago
That's true, and Rust compiler speed has seen similar speedups from lots of 1% improvements. But even if you can get a 2x improvement from lots of 1% improvements (if you work really really hard), you're never going to get a 10x improvement. Rust is never going to compile remotely as quickly as Go. Python is never going to be remotely as fast as Rust, C++, Go, Java, C#, Dart, etc.
- inglor_cz 3y ago
  Does it matter? Trains are never going to beat jets in pure speed. But in certain scenarios, trains make a lot more sense to use than jets, and in those scenarios, it is usually preferable having a 150 mph train to a 75 mph train. Looking at the world of railways, high-speed rail has attracted a lot more paying customers than legacy railways, even though it doesn't even try to achieve flight-like speeds. Same with programming languages, I guess.
  - fl0ki 3y ago
    What is the programming analogy here? Two decades ago, you could (as e.g. Paul Graham did at the time) argue that dynamically typed languages can get your ideas to market faster so you become viable and figure out optimization later. It's been a long time since that argument held. Almost every dynamic programming language still under active development is adding some form of gradual typing because the maintainability benefits alone are clearly recognized, though such languages still struggle to optimize well. Now there are several statically typed languages to choose from that get those maintainability benefits up-front and optimize very well. Different languages can still be a better fit for different projects, e.g. Rust, Go, and Swift are all statically typed compiled languages better fit for different purposes, but in your analogy they're all jets designed for different tactical roles, none of them are "trains" of any speed. Analogies about how different programming languages are like different vehicles or power tools or etc go way back and have their place, but they have to recognize that sometimes one design approach largely supersedes another for practical purposes. Maybe the analogy would be clearer comparing jets and trains which each have their place, to horse-drawn carriages which still exist but are virtually never chosen for their functional benefits.

spacechild1 3y ago

> "remember that CPython is already written in C" What is this supposed to say? Most scripting language interpreters are written in low level languages (or assembly), but that alone doesn't say anything about the performance of the language itself.

nertirs 3y ago
This means, that a lot of python libraries like polars or tensorflow are written not in python. So python programs, that already spend most of its cpu time running these libraries code, won't see much of an impact.
- gh02t 3y ago
  Isn't the point that if pure Python was faster they wouldn't need to be written in other [compiled] languages? Having dealt with Cython it's not bad, but if I could write more of my code in native Python my development experience would be a lot simpler. Granted we're still very far from that and probably won't ever reach it, but there definitely seems to be a lot of progress.
  - __MatrixMan__ 3y ago
    Since Nim compiles to C, a middle step worth being aware of is Nim + nimporter which isn't anywhere near "just python" but is (maybe?) closer than "compile a C binary and call it from python". Or maybe it's just syntactic sugar around that. But sugar can be nice.
eequah9L 3y ago
I think they mean that a lot of runtime of any benchmark is going to be spent in the C bits of the standard library, and therefore not subject to the JIT. Only the glue code and the bookkeeping or whatnot that the benchmark introduces would be improved by the JIT. This reduces the impact that the JIT can make.