Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.14 is here. How fast is it?

blog.miguelgrinberg.com

Post reply on HN
Print view View original

481–490 of 579 posts

Re: Python 3.14 is here. How fast is it?

#481

Post by wbolt »

ActorNightly wrote: post #361
wbolt wrote: post #343

More than 300 comments here and still no convincing answer. Why the community wastes time on trying to make CPython faster when there is pypy which is already much faster? I understand pypy lacks libraries and feature parity with up to date CPython. But… can’t everyone refocus the efforts and just move to pypy to add all the missing bits and then just continue with pypy as the “official python”? Are there any serious…

> Are there any serious technical reasons not to do it? Yes. First is startup time. REPL cycle being fast is a big advantage for development. From a business perspective, dev time is more expensive then compute time by orders of magnitude. Every time you make a change, you have to recompile the program. Meanwhile with regular python, you can literally develop during execution. Second is compatibility. Numpy and pytor…

Repl I get it. Possibly valid point. Yet I guess same issue are valid to node.js which seems much faster in many cases and still has valid dev experience.

C compatibility / extension compatibility - nope. First, it is an issue of limited resources. Add more devs to pypy team and compatibility bugs gets fixed. Second, aren’t people writing C extensions due to python being slow? Make python fast - as pypy - and for some cases native code won’t be that crucial.

So I don’t see a real issue with pypy that could not be solved by simply moving all the dev efforts from CPython.

So are there political, personal or business issues?

Re: Python 3.14 is here. How fast is it?

#482

Post by mathattack »

xp84 wrote: post #122
miguelgrinberg wrote: post #34

Earlier quoted context omitted.

You have made my day, sir. :)

Absolutely love seeing like a dozen people piling on Mr Grinberg to show gratitude for his work, and indeed the even little things he does to help uplift others in the field. It’s a good reminder that a small helpful contribution, or bit of teaching given at the right time, can be so valuable!

Please note the Buy Me Coffee button at the bottom of the post.

Re: Python 3.14 is here. How fast is it?

#483

Post by lxgr »

feoren wrote: post #82
amelius wrote: post #27

I hope it doesn't get stuck at 3.14, like TeX. https://www.reddit.com/r/RedditDayOf/comments/7we430/donald_...

You hope it doesn't ? > [Donald Knuth] firmly believes that having an unchanged system that will produce the same output now and in the future is more important than introducing new features This is such a breath of fresh air in a world where everything is considered obsolete after like 3 years. Our industry has a disease, an insatiable hunger for newness over completeness or correctness . There's no reason we can't…

> There's no reason we can't be writing code that lasts 100 years. Code is just math.

The weather forecast is also “just math”, yet yesterday’s won’t be terribly useful next April.

Re: Python 3.14 is here. How fast is it?

#484

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #326

Only tested against NodeJS and Rust What about Lua and LuaJIT

If faster language interpreters were included in the tests, the title could be "Python 3.14 is here. How slow is it?"

It would be interesting to test intepreter startup time across various intepreter including Python

Re: Python 3.14 is here. How fast is it?

#485

Post by 9rx »

Someone wrote: post #434
0xDEAFBEAD wrote: post #407

Earlier quoted context omitted.

>evolved Yes, it evolved. It wasn't designed. >Version numbers? Without version numbers, it has to be backwards-compatible, making it difficult to remove cruft. What would programming be like if all the code you wrote needed to work as IBM mainframe assembly? Tau is a good case study. Everyone seems to agree tau is better than pi. How much adoption has it seen? Is this what "heavy optimization" looks like? It took hu…

> Without version numbers, it has to be backwards-compatible If there’s one thing that mathematical notation is NOT, it’s backwards compatible. Fields happily reuse symbols from other fields with slightly or even completely different meanings. https://en.wikipedia.org/wiki/Glossary_of_mathematical_symbo... has lots of examples, for example ÷ (division sign) Widely used for denoting division in Anglophone countries, i…

> Fields happily reuse symbols from other fields with slightly or even completely different meanings.

Symbol reuse doesn't imply a break in backwards compatibility. As you suggest with "other fields", context allows determining how the symbols are used. It is quite common in all types of languages to reuse symbols for different purposes, relying on context to identify what purpose is in force.

Backwards incompatibility tells that something from the past can no longer be used with modern methods. Mathematical notation from long ago doesn't much look like what we're familiar with today, but we can still make use of it. It wasn't rendered inoperable by modern notation.

Re: Python 3.14 is here. How fast is it?

#486

Post by haberman »

miguelgrinberg wrote: post #248
ufo wrote: post #240

Earlier quoted context omitted.

The tail calls in question are C tail calls inside the inner interpreter loop. They have nothing to do with Python function calls.

That tells you how much I know about the feature. :) But in any case, I'm positive that the flag was enabled, so my results are with tail calls. I suppose part of the difference between 3.13 and 3.14 could be thanks to this.

Good to know! Thanks for confirming. Yes, I would guess that the tail call interpreter explains part of the difference between 3.13 and 3.14. Previously the overall improvement to the interpreter has been measured at 1-5%, or even 10-15% depending on the compiler version you are using: https://blog.nelhage.com/post/cpython-tail-call/

If your benchmark setup is easy to re-run, it would be awesome to see numbers that compare the tail call interpreter to the build where it is disabled, to isolate how much improvement is due to that.

Re: Python 3.14 is here. How fast is it?

#487

Post by ModernMech »

wbolt wrote: post #343

More than 300 comments here and still no convincing answer. Why the community wastes time on trying to make CPython faster when there is pypy which is already much faster? I understand pypy lacks libraries and feature parity with up to date CPython. But… can’t everyone refocus the efforts and just move to pypy to add all the missing bits and then just continue with pypy as the “official python”? Are there any serious…

> Are there any serious technical reasons not to do it?

Forget technical reasons, how would you ever do it? It feels like the equivalent of cultural reprogramming "You must stop using your preferred interpreter and halt all your efforts contrary to the one true interpreter". Nah, not going to happen in a free and open source language. Who would have the authority and control to make such a directive?

Yes, there may be technical reasons, but the reason it doesn't happen more than any other is that programming languages are languages spoken by people, and therefore they evolve organically at no one's direction. Even in languages like Python with a strong bent for cultural sameness and a BDFL type direction, they still couldn't control it. Often times, dialects happen for technical reasons, but it's hard to get rid of them on technical grounds.

Re: Python 3.14 is here. How fast is it?

#488

Post by ActorNightly »

lunias wrote: post #452
ActorNightly wrote: post #365

Earlier quoted context omitted.

Why? There are other languages you can use to make stuff go fast. Python isn't for making stuff go fast. Its for rapid dev, and that advantage matters way more when you already are going to be slow due to waiting for network response

This has always confused me... is Python really that much better at rapid dev? I work on a Python project and every day I wish the people that started the project had chosen a different language that actually scaled well with the problem rather than Python, which they likely chose because it was for "rapid dev".

You can run Python processes in parallel for "scaling". Youtube and Uber run python backends. This is cheaper than developer time per hour.

Re: Python 3.14 is here. How fast is it?

#489

Post by [deleted] »

mystifyingpoi wrote: post #399
procaryote wrote: post #374

Earlier quoted context omitted.

I really hope I'll never need to touch code written by people who code in python and throws it at a plausible randomiser to get java or C If you for some reason do this, please keep the python around so I can at least look at whatever the human was aiming at. It's probably also wrong as they picked this workflow, but there's a chance it has something useful

I get the "old man yells at cloud" vibes from your comment. Who cares how he got the result? I thought our job is to create working software. If this flow works for him and creates code that meets company standards, then more power to him. However, if the output quality is crap, then well, maybe his creativity should not be rewarded. I've seem hefty amount of Map in Java, written primarily by JS developers.

[deleted]

Re: Python 3.14 is here. How fast is it?

#490

Post by ActorNightly »

procaryote wrote: post #374
ActorNightly wrote: post #361

Earlier quoted context omitted.

> Are there any serious technical reasons not to do it? Yes. First is startup time. REPL cycle being fast is a big advantage for development. From a business perspective, dev time is more expensive then compute time by orders of magnitude. Every time you make a change, you have to recompile the program. Meanwhile with regular python, you can literally develop during execution. Second is compatibility. Numpy and pytor…

I really hope I'll never need to touch code written by people who code in python and throws it at a plausible randomiser to get java or C If you for some reason do this, please keep the python around so I can at least look at whatever the human was aiming at. It's probably also wrong as they picked this workflow, but there's a chance it has something useful

LLMs are there to get the meat of the software in. Fine tuning it is easy when you already have all the syntax written for you. With enough prompting on how you want the code laid out, the modern models do a really good job of getting it right with very minor things you have to tweak.
Post reply on HN