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

321–330 of 579 posts

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

#325

Post by Rohansi »

cap11235 wrote: post #282
b3orn wrote: post #131

Earlier quoted context omitted.

It's two different computers with different CPUs, so different runtimes are expected and has nothing to do with the OS. > Framework laptop running Ubuntu Linux 24.04 (Intel Core i5 CPU) > Mac laptop running macOS Sequoia (M2 CPU)

Yes, and why? way to not address the question at all.

Are you asking why the M2 is faster than the i5?

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

#327

Post by josephg »

kibwen wrote: post #223
7952 wrote: post #205

Earlier quoted context omitted.

Given how mature emulation is now why couldn't that just continue to be possible into the future?

Each new layer of emulation is new code that needs to be written that wasn't required when the original program in question was written. It's a great approach for software preservation, but the fact that it's necessary shows why the approach of "if it ain't broke, don't fix it" doesn't work. The context of computing is changing around us at all times, and hardware has a finite lifespan.

Eh. Emulators are often tiny in comparison to the programs they emulate. Especially when performance isn't so much of a concern - like when you're emulating software written for computers from many decades ago. A good emulator can also emulate a huge range of software. Just look at programs like dosbox and the like. Or Apple's great work with Rosetta and Rosetta2 - which are both complex, but much less complex than all the software they supported. Software like Chrome, Adobe Photoshop and the Microsoft office suite.

Arguably modern operating systems are all sort of virtual machine emulators too. They emulate a virtual computer which has special instructions to open files, allocate memory, talk to the keyboard, make TCP connections, create threads and so on. This computer doesn't actually exist - its just "emulated" by the many services provided by modern operating systems. Thats why any windows program can run on any other windows computer, despite the hardware being totally different.

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

#328

Post by 0xDEAFBEAD »

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…

To be fair, if math did have version numbers, we could abandon a lot of hideous notational cruft / symbol overloading, and use tau instead of pi. Math notation is arguably considerably worse than perl -- can you imagine if perl practically required a convention of single-letter variable names everywhere? What modern language designer would make it so placing two variable names right next to each other denotes multiplication? Sheer insanity.

Consider how vastly more accessible programming has become from 1950 until the present. Imagine if math had undergone a similar transition.

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

#329

Post by rFlex »

moralestapia wrote: post #32

Very interesting post, thanks for putting it together. Rust is indeed quite fast, I thought NodeJS was much better tbh., although it's not bad. I'd be interested to learn what's holding it back because I've seen many implementations where V8 can get C++-like performance (I mean it's C++ after all). Perhaps there's a lot of overhead in creating/destroying temporary objects.

For the bubble sort implementation, it's due to the use of the destructuring assignment in the benchmark code. When swapping to a regular swap using a temporary variable, the benchmark runs more than 4 times faster on my machine. Still not at Rust level of performance, but a bit closer to it.
Post reply on HN