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

Free-threaded CPython is ready to experiment with

labs.quansight.org

Post reply on HN
Print view View original

391–398 of 398 posts

Re: Free-threaded CPython is ready to experiment with

#391

Post by phkahler »

fastasucan wrote: post #388
phkahler wrote: post #25

Earlier quoted context omitted.

I feel like most things that will benefit from moving to multiple cores for performance should probably not be written in Python. OTH "most" is not "all" so it's gonna be awesome for some.

I never understand this sentiment, that shows up in every topic on python. Who descides why something should or should not be written I Python? Why shouldn't someone who prefers writing in python benefit from using multiple cores?

>> Who descides why something should or should not be written I Python? Why shouldn't someone who prefers writing in python benefit from using multiple cores?

I did use the words "most things". I'm not saying this is a bad development for Python, or that nobody should use it. But if performance is a top priority, Python is the wrong language and always has been.

I use Python from time to time, it's fun and easy to put certain kinds of things together quickly. But each time I do a project with it, the first thing I ask myself is "is this going to be fast enough?" If not I'll use something else.

Re: Free-threaded CPython is ready to experiment with

#392

Post by thebigspacefuck »

grandimam wrote: post #241

How is the no-gil performance compared to other languages like - javascript (nodejs), go, rust, and even java? If it's bearable then I believe there is enormous value that could be generated instead of spending time porting to other languages.

Here’s a benchmark https://github.com/lip234/python_313_benchmark

It’s much worse except in everything but a threaded test

Re: Free-threaded CPython is ready to experiment with

#393

Post by fuzztester »

jacob019 wrote: post #315
fuzztester wrote: post #211

Earlier quoted context omitted.

it may not be tactful but it sure is factful (even if that last word is ungrammatical, at least the sentence is poetical). he he he. jfc. guido knows ;), this thread is getting weirder and weirder, creepier and creepier. are you literally implying that I should lie about known facts about python slowness? "tactful" my foot. then I guess the creators of PyPy and Unladen Swallow (the latter project was by Google) were/…

tactful - showing skill and sensitivity in dealing with people. Right or wrong, your comments do not contribute to the discussion. Open source development is about collaboration. Your irrelevant comments are disrespectful to all the hard working developers who have been working together to push the limits of what is possible with what may be the most widely used programming language of our time. I use Python for it's…

>tactful - showing skill and sensitivity in dealing with people. Right or wrong, your comments do not contribute to the discussion.

just take a look at the depth of your incredibly rotten stupidity and ugliness of mind, you fucktard and dotard (dotard means something like a senile person, in case you didn't know):

hn user jacob019, you little mofo:

you say that "Right or wrong, your comments do not contribute to the discussion."

that itself is a contradiction in terms.

so you are saying that my comments do not contribute to the discussion even if i am right?

(what an utter fool and liar and swine you are.)

then why should i and anyone else think that your comments contribute to the discussion when they so totally fucking wrong, biased, shitheaded, pissheaded, and other choice epithets?

comgrats, you have really jumped the shark in terms of being a creep.

enjoy your miserable life for what it is worth, you worm.

Re: Free-threaded CPython is ready to experiment with

#394

Post by GTP »

radarsat1 wrote: post #335
GTP wrote: post #46

Earlier quoted context omitted.

Then we have very different ideas of what proper typing is :D Look at this function, can you tell me what it does? def plus(x, y): return x+y If your answer is among the lines of "It returns the sum x and y" then I would ask you who said that x and y are numbers. If these are strings, it concatenates them. If instead you pass a string and a number, you will get a runtime exception. So not only you can't tell what a f…

And if you specify that they are numbers then you lose the ability of the function to generalize to vectors. Indeed assuming it adds two things is correct, and knowing that concatenation is how Python defines adding strings is important for using the language in the intended way.

What about the case of passing a number and a string?

Re: Free-threaded CPython is ready to experiment with

#395

Post by jodrellblank »

phkahler wrote: post #390
jodrellblank wrote: post #182

Earlier quoted context omitted.

https://www.servethehome.com/wp-content/uploads/2023/01/Inte... AMD EPYC 9754 with 128-cores/256-threads, and EPYC 9734 with 112-cores/224-threads. TomsHardware says they "will compete with Intel's 144-core Sierra Forest chips, which mark the debut of Intel's Efficiency cores (E-cores) in its Xeon data center lineup, and Ampre's 192-core AmpereOne processors". What in 5 years? 10? 20? How long will "1 core should be…

>> What in 5 years? 10? 20? How long will "1 core should be enough for anyone using Python" stand? If you're looking for a 32x or 128x performance improvement from python supporting multi-core you should probably rewrite in C, C++, Rust, or Fortran and get that 100x improvement today on a single core. If done properly you can then ALSO get the gain from multiple cores on top of that. Or to put it another way, if perf…

"instead of taking advantage of hardware you own, you should do a LOT of work in a language you don't know" - how is that in any way a reasonable suggestion or alternative?

> "Or to put it another way, if performance is critical python is a poor choice."

To put it another way, just because performance isn't critical, doesn't mean that more performance for free is not desirable or beneficial, or that ignoring 127/128ths of available performance is fine.

Re: Free-threaded CPython is ready to experiment with

#396

Post by bdd8f1df777b »

Certhas wrote: post #281
bdd8f1df777b wrote: post #195

Earlier quoted context omitted.

> Code that needs performance and would benefit from multithreading, usually written by professional software engineers, likely isn't written in Python in the first place. There are a lot of simple cases where multi-threading can easily triple or quadruple the performance.

But multiprocessing can't? I used to write a ton of MPI based parallel python. It's pretty straightforward. But one could easily imagine trying to improve the multiprocessing ergonomics rather than introducing threading. Obviously the people who made the choice to push forward with this are aware of these options, too. Still mildly puzzling to me why threads for Python are needed/reasonable.

A common pain point for me is parallel data loading and processing for PyTorch or TensorFlow. Multiprocessing has a lot of bugs and pain points to deal with when doing ML. Examples: https://github.com/search?q=repo%3Apytorch%2Fpytorch+multipr.... Most of these issues do not exist in a multithreading world, because resource sharing is trivial in that case.

Since Python leads over any other languages in the ML community, and ML is a hot topic right now, it makes sense for Python developers to secure the lead by making the life of ML developers easier, which is by introducing GIL-less multi-threading.

Re: Free-threaded CPython is ready to experiment with

#397

Post by mondrian »

kaba0 wrote: post #367
mondrian wrote: post #299

Earlier quoted context omitted.

Python is dynamically typed because it type-checks at runtime, regardless of annotations or what mypy said.

Is java dynamically typed as well, then? It does reify generics, so only some part is type checked, what is the level at which it is statically/dynamically typed?

Yeah Java is partially dynamically typed. I think we can safely conclude that all practical languages are hybrids where some of the type checking is done by the compiler and some of the type checking is deferred to the runtime.

Then when we call a language statically typed we mean most of the type checking is usually done statically. Dynamic type checking is the exception, not the rule.

Even in dynamically typed languages like Python, some of the type checking may be done by an optimizer in the compilation stage. The runtime type check guarding some operations may be removed, because the optimizer decides it knows the types of the values involved once and for all.

Re: Free-threaded CPython is ready to experiment with

#398

Post by jacob019 »

fuzztester wrote: post #393
jacob019 wrote: post #315

Earlier quoted context omitted.

tactful - showing skill and sensitivity in dealing with people. Right or wrong, your comments do not contribute to the discussion. Open source development is about collaboration. Your irrelevant comments are disrespectful to all the hard working developers who have been working together to push the limits of what is possible with what may be the most widely used programming language of our time. I use Python for it's…

>tactful - showing skill and sensitivity in dealing with people. Right or wrong, your comments do not contribute to the discussion. just take a look at the depth of your incredibly rotten stupidity and ugliness of mind, you fucktard and dotard (dotard means something like a senile person, in case you didn't know): hn user jacob019, you little mofo: you say that "Right or wrong, your comments do not contribute to the…

Seems I hit a nerve. We never stop growing. Good luck to you friend.
Post reply on HN