Python 3.11 vs 3.10 performance • Hacker News Board

Re: Python 3.11 vs 3.10 performance

#211

Post by maxloh » Wed, Jul 06, 2022, 6:20 PM UTC

staticassertion wrote: post #88

sod wrote: post #14

I wish there was something like llvm for scripting languages. Imagine if python, php, javascript, dart or ruby would not interpret the code themself, but compile to an interpretable common language, where you could just plug in the fastest interpreter there is for the job.

https://github.com/mypyc/mypyc > Mypyc compiles Python modules to C extensions. It uses standard Python type hints to generate fast code. Mypyc uses mypy to perform type checking and type inference.

You can't compile to an executable with mypyc, just native C extensions.

Re: Python 3.11 vs 3.10 performance

#212

Post by 8organicbits » Wed, Jul 06, 2022, 6:21 PM UTC

timoteostewart wrote: post #194

8organicbits wrote: post #185

Earlier quoted context omitted.

"Debugging is twice as hard as writing the code in the first place. Therfore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Rajanand Although, personally, I enjoy python list comprehensions.

I believe that quote about debugging being twice as hard as coding is by Brian Kernighan. https://en.m.wikiquote.org/wiki/Brian_Kernighan

Maybe, I grabbed the first matching quote I found. I can't attribute it on my own.

Re: Python 3.11 vs 3.10 performance

#213

Post by KptMarchewa » Wed, Jul 06, 2022, 6:22 PM UTC

coldtea wrote: post #126

dragonwriter wrote: post #97

Earlier quoted context omitted.

Those people were not being paid to speed up CPython, though, but mostly-source-compatible (but not at all native extension compatible) alternative interpreters.

That's because the core team wasn't friendly to them making changes in CPython. Not because they deliberately only wanted to build an alternative interpreter.

Core team wasn't friendly to breaking C API.

Current changes don't really break it.

Re: Python 3.11 vs 3.10 performance

#214

Post by lispm » Wed, Jul 06, 2022, 6:27 PM UTC

wheybags wrote: post #130

tasubotadas wrote: post #106

Earlier quoted context omitted.

>Python being interpreted is the main reason why it’s slow Common Lisp and Java begs to disagree.

Jvm at least is jitted, not interpreted. Dunno anything about common lisp.

Common Lisp has several compilers generating machine code AOT. See for example http://www.sbcl.org

Re: Python 3.11 vs 3.10 performance

#215

Post by lanstin » Wed, Jul 06, 2022, 6:27 PM UTC

zitterbewegung wrote: post #136

gostsamo wrote: post #94

Earlier quoted context omitted.

O, I agree. As I said, when python and its uses scaled, it became quite necessary to make it fast. I like that it will be fast as well and I am not happy that it is slow at the moment. My point is that there are reasons why it was not optimized in the beginning and why this process of optimizations has started now.

Back when Python was started there was really C or C++ for optimized programs and scripting languages like Python and Perl. But since Python had the ability for C Extensions it allowed it to bypass those problems. Since Python was easy to learn both web developers and scientists to learn. Then financial organizations started to get interested and that’s really how Python cemented itself. What exactly do you do with P…

I worked on Python almost exclusively for maybe five years. Then I tried go. Each time I wrote a go program, I am giddy with excitement at how fast my first attempt is, scaling so smoothly with the number of cores. I also wrote a lot of fairly performant C in the 90s, so I know what computers can do in a second.

I still use Python for cases when dev time is more important than execution time (which is rarer now that I'm working adjacent to "big data") or when I'm doing things like writing python to close gaps in the various arrays of web apps provided for navigating the corporate work flow, and if I went as fast as a 64 core box let me, we'd have some outages in corp github or artifactory or the like, so I just do it one slow thing at a time on 1 core and wait for the results. Maybe multiprocessing with 10 process worker pool once I'm somewhat confident in the back end system I am talking to.

(edit: removed my normal email signoff)

Re: Python 3.11 vs 3.10 performance

#216

Post by atwood22 » Wed, Jul 06, 2022, 6:29 PM UTC

YesThatTom2 wrote: post #180

atwood22 wrote: post #149

Earlier quoted context omitted.

Yes, you can spend a large amount of time making things faster. But note that Go's GC is fast, even though it is simple. It's not the fastest, but it is acceptably fast.

Funny you should pick that example in a sub thread that you started with an assertion that code should be fast from by default. Go’s GC was intentionally slow at first. They wanted to get it right THEN make it fast. No offense but you’re not making a strong case. You’re sounding like an inexperienced coder that hasn’t yet learned that premature optimization is bad.

Just FYI, Go's GC mantra is "GC latency is an existential threat to Go."

Re: Python 3.11 vs 3.10 performance

#217

Post by zo1 » Wed, Jul 06, 2022, 6:29 PM UTC

atwood22 wrote: post #151

soperj wrote: post #85

Earlier quoted context omitted.

When you only have so many hours to go around, you concentrate on the main goals.

My point is that you can write fast code just as easily as you can write slow code. So engineers should write fast code when possible. Obviously you can spend a lot of time making things faster, but that doesn't mean you can't be fast by default.

Being fast requires effort. It's not always about raw performance of the language yo use, it's about using the right structures, algorithms, tradeoffs, solving the right problems, etc. It's not trivial and I've seen so many bad implementations in "fast" compiled languages.

Re: Python 3.11 vs 3.10 performance

#218

Post by zo1 » Wed, Jul 06, 2022, 6:32 PM UTC

uoaei wrote: post #200

BeetleB wrote: post #147

Earlier quoted context omitted.

> Things should be fast by default. In over 90% of my work in the SW industry, being fast(er) was of no benefit to anyone. So no, it should not be fast by default.

Ha! Good luck convincing end-users that that's true.

Client doesn't care. As long as their advertising spend leads to conversion into your "slow" app, they're happy.

Re: Python 3.11 vs 3.10 performance

#219

Post by didip » Wed, Jul 06, 2022, 6:32 PM UTC

antman wrote: post #208

There was always a denial of removing the Global Interpreter Lock because it would decrease single threaded Python speed for which most people din’t care. So I remember a guy recently came up with a patch that both removed GIL and also to make it easier for the core team to accept it he added also an equivalent number of optimizations. I hope this release was is not we got the optimizations but ignored the GIL part.…

I agree, please don't just accept the optimization and sweep the GIL removal under the rug again.

Re: Python 3.11 vs 3.10 performance

#220

Post by bornfreddy » Wed, Jul 06, 2022, 6:33 PM UTC

hn_saver wrote: post #103

sgtlaggy wrote: post #38

Earlier quoted context omitted.

Concurrency in Python is a weird topic, since multiprocessing is the only "real" concurrency. Threading is "implicit" context switching all in the same process/thread, asyncio is "explicit" context switching. On top of that, you also have the complication of the GIL. If threads don't release the GIL, then you can't effectively switch contexts.

Threading IS concurrency. When you say "real" concurrency, you actually mean parallelism.

Not in CPython it isn't. Threading in CPython doesn't allow 2 threads to run concurrently (because of GIL). As GP correctly stated, you need multiprocessing (in CPython) for concurrency.