Earlier quoted context omitted.
What languages do you think it could realistically eat (that it hasn’t already)?
Javascript, if it becomes viable for web development?
It already is as viable for web development as JS is.
Python 3.13 Gets a JIT
441–450 of 553 posts
Re: Python 3.13 Gets a JIT
#442Earlier quoted context omitted.
Compunding a decrease works differently than an increase. If something gets 10% faster twice it actually got 19% faster. In other words, the runtime is 90% of 90%, i.e. 81%.
Not if “faster” refers to computation rate rather than runtime, in which case it becomes 100/81 i.e. 23% faster.
Yes, but I’ve literally never heard anyone say that.
Re: Python 3.13 Gets a JIT
#443It's interesting to see these 2-9% improvements from version to version. They are always talked about with disappointment, as if they are too small, but they also keep coming, with each version being faster than the previous one. I prefer a steady 10% per version over breaking things because you are hoping for bigger numbers. Those percentages add up!
This is happening mostly because Guido left, right? The take that CPython should be a reference implementation and thus slow always aggravated me (because, see, no other implementation can compete because every package depends on CPython kirks, in such a way that we're now removing the GIL of CPython rather than migrating to Pypy for example)
Seems a bit silly to think that- Guido is still involved with Python... and in fact is the one heading the Faster CPython project at Microsoft which is responsible for many of these improvements.
Re: Python 3.13 Gets a JIT
#444[deleted]
Re: Python 3.13 Gets a JIT
#445Earlier quoted context omitted.
Sorry, but reality bites https://en.wikipedia.org/wiki/Amdahl%27s_law
It's not that simple. Amdahl's Law is about expected speedup/decrease in latency. That actually isn't strongly correlated to "saving the planet" afaik (where I interpret that as reducing direct energy usage, as well as embodied energy usage by reducing the need to upgrade hardware). If anything, increasing speed and/or decreasing latency of the whole system often involves adding some form of parallelism, which brings…
[deleted]
Re: Python 3.13 Gets a JIT
#446Earlier quoted context omitted.
It's fascinating to me that this process seems to rhyme with that of the path PHP took, with HHVM being built as a second implementation, proving that PHP could be much faster -- and the main project eventually adopting similar approaches. I wonder if that's always likely to happen when talking about languages as big as these are? Can a new implementation of it ever really compete?
similar with vim vs neovim as well
Can you elaborate? Genuinely interested.
Re: Python 3.13 Gets a JIT
#447[flagged]
Could you please stop posting flamewar comments, in particular about Python? You've done it repeatedly in this thread, as well as on many other occasions (e.g. https://news.ycombinator.com/item?id=38010109), and we've already had to ask you more than once to stop:
https://news.ycombinator.com/item?id=38270168 (Nov 2023)
https://news.ycombinator.com/item?id=37807607 (Oct 2023)
This is not about Python, it's about not having tedious squabbles (or worse) on HN. We'd make the same request of any user on any topic. Sometimes a commenter is fixated on a particular topic, can't let go, and posts way too many low-quality and/or hostile comments about it. That's definitely not an ok use of HN, and we eventually have to ban such accounts.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
Re: Python 3.13 Gets a JIT
#448It's interesting to see these 2-9% improvements from version to version. They are always talked about with disappointment, as if they are too small, but they also keep coming, with each version being faster than the previous one. I prefer a steady 10% per version over breaking things because you are hoping for bigger numbers. Those percentages add up!
This is happening mostly because Guido left, right? The take that CPython should be a reference implementation and thus slow always aggravated me (because, see, no other implementation can compete because every package depends on CPython kirks, in such a way that we're now removing the GIL of CPython rather than migrating to Pypy for example)
Pypy actually works really well. It could probably get even farther if people knew about it more.
Test your packages on Pypy, people.
Re: Python 3.13 Gets a JIT
#449Finally! Regardless of the work being done in PyPy, Jython, GraalPy and IronPython, having a JIT in CPython seems to be the only way beyond "C/C++/Fortran libs are Python" mindset. Looking forward to its evolution, from 3.13 onwards.
The only way to achieve C/C++/Fortran efficiency is a statically compiled, strongly typed language. Witness the effort put into Java JITC and the rest of the modern Java (and Graal) runtime. Still well short of the promised “C equivalence”.
To me, Mojo looks like the best approach to fusing that with the Python ecosystem! (I have no doubt about it being open sourced at some point.)
Re: Python 3.13 Gets a JIT
#450Earlier quoted context omitted.
I personally like Quart, which is like Flask, but with asyncio. Django is also incredibly popular and has been around forever, so it is very battle-tested.
I've been using FastAPI which is made by the same guy as Flask but taking it seriously this time and using asyncio and making space for multithreaded. It's almost a drop-in replacement for Flask.
FastAPI was created by Sebastián Ramírez (tiangolo) and flask was created by Armin Ronacher.