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

111–120 of 579 posts

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

#111

Post by famouswaffles »

ModernMech wrote: post #3

I'm thankful they included a compiled language for comparison, because most of the time when I see Python benchmarks, they measure against other versions of Python. But "fast python" is an oxymoron and 3.14 doesn't seem to really change that, which I feel most people expected given the language hasn't fundamentally changed. This isn't a bad thing; I don't think Python has to be or should be the fastest language in th…

It's pretty simple. Nobody wants to do ML R&D in C++.

Tensorflow is a C++ library with python bindings. Pytorch has supported a C++ interface for some time now, yet virtually nobody uses C++ for ML R&D.

The relationship between Python and C/C++ is the inverse of the usual backend/wrapper cases. C++ is the replaceable part of the equation. It's a means to an end. It's just there because python isn't fast enough. Nobody would really care if some other high perf language took its place.

Speed is important, but C++ is even less suited for ML R&D.

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

#113

Post by Q6T46nT668w6i3m »

pooyamo wrote: post #105
feoren wrote: post #82

Earlier quoted context omitted.

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…

Some stuff like LAPACK and BLAS fit your bill. They are math libraries written decades ago and still in use.

LAPACK and OpenBLAS regularly release new versions

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

#114

Post by kstrauser »

liuliu wrote: post #98
the__alchemist wrote: post #23

Earlier quoted context omitted.

That's because you're doing web stuff. (I/O limited). So much of our computing experience has been degraded due to this mindset applied more broadly. Despite a steady improvement in hardware, my computing experiences have been stagnating and degraded in terms of latency, responsiveness etc. I'm not going to even go into the comp chem simulations I've been running, or that about 1/3 the stuff I do is embedded. I do st…

And 300ms for a DB call is slow, in any case. We really shouldn't accept that as normal cost of doing business. 300ms is only acceptable if we are doing scrypt type of things.

> in any case.

In some cases. Are looking up a single indexed row in a small K-V table? Yep, slow. Are you generating reports on the last 6 years of sales, grouped by division within larger companies? That might be pretty fast.

I'm not sure why you'd even generalize that so overly broadly.

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

#115

Post by AAAAaccountAAAA »

bitwize wrote: post #108
feoren wrote: post #82

Earlier quoted context omitted.

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…

Except uh, nobody uses infinitesimals for derivatives anymore, they all use limits now. There's still some cruft left over from the infinitesimal era, like this dx and dy business, but that's just a backwards compatibility layer. Anyhoo, remarks like this are why the real ones use Typst now. TeX and family are stagnant, difficult to use, difficult to integrate into modern workflows, and not written in Rust.

Even if Typst was going to replace TeX everywhere right now, about half a century would still be a respectable lifespan for a software project.

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

#117

Post by lenerdenator »

kstrauser wrote: post #33
the__alchemist wrote: post #23

Earlier quoted context omitted.

That's because you're doing web stuff. (I/O limited). So much of our computing experience has been degraded due to this mindset applied more broadly. Despite a steady improvement in hardware, my computing experiences have been stagnating and degraded in terms of latency, responsiveness etc. I'm not going to even go into the comp chem simulations I've been running, or that about 1/3 the stuff I do is embedded. I do st…

I won’t completely argue against that, and I’ve also adopted Rust for smaller or faster work. Still, I contend that a freaking enormous portion of computing workloads are IO bound to the point that even Python’s speed is Good Enough in an Amdahl’s Law kind of way.

It's been said that Python's greatest superpower is that it's the second-best language at the most stuff.

No one's really developed an ecosystem for a language that's more performant that can match it, and that's all it needs to assert dominance.

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

#118

Post by feoren »

bitwize wrote: post #108
feoren wrote: post #82

Earlier quoted context omitted.

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…

Except uh, nobody uses infinitesimals for derivatives anymore, they all use limits now. There's still some cruft left over from the infinitesimal era, like this dx and dy business, but that's just a backwards compatibility layer. Anyhoo, remarks like this are why the real ones use Typst now. TeX and family are stagnant, difficult to use, difficult to integrate into modern workflows, and not written in Rust.

> the real ones use Typst now

Are you intentionally leaning into the exact caricature I'm referring to? "Real programmers only use Typstly, because it's the newest!". The website title for Typst when I Googled it literally says "The new foundation for documents". Its entire appeal is that it's new? Thank you for giving me such a perfect example of the symptom I'm talking about.

> TeX and family are stagnant, difficult to use, difficult to integrate into modern workflows, and not written in Rust.

You've listed two real issues (difficult to use, difficult to integrate), and two rooted firmly in recency bias (stagnant, not written in Rust). If you can find a typesetting library that is demonstrably better in the ways you care about, great! That is not an argument that TeX itself should change. Healthy competition is great! Addiction to change and newness is not.

> nobody uses infinitesimals for derivatives anymore, they all use limits now

My point is not that math never changes -- it should, and does. However, math does not simply rot over time, like code seems to (or at least we simply assume it does). Math does not age out. If a math technique becomes obsolete, it's only ever because it was replaced with something better. More often, it forks into multiple different techniques that are useful for different purposes. This is all wonderful, and we can celebrate when this happens in software engineering too.

I also think your example is a bit more about math pedagogy than research -- infinitesimals are absolutely used all the time in math research (see Nonstandard Analysis), but it's true that Calculus 1 courses have moved toward placing limits as the central idea.

Post reply on HN