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

gh-116167: Allow disabling the GIL

github.com

Post reply on HN
Print view View original

191–200 of 259 posts

Re: gh-116167: Allow disabling the GIL

#191

Post by DinaCoder98 »

agent281 wrote: post #179
rnmmrnm wrote: post #36

More than seeing it in main, I'm happy for the "python thread slow" meme officially going away now.

I doubt that Python will ditch the meme. The fundamental model of dynamic dispatch using dictionaries on top of a byte code interpreter is pretty slow. I wouldn't expect it to get within 2x of JavaScript.

Javascript may not have an official bytecode, but is it not also based on the same concept of using dictionaries to dispatch code and slow as a result? I certainly had always filed it away as "about as fast as python" in my head. Why else would it rely on evented i/o?

Re: gh-116167: Allow disabling the GIL

#192

Post by Intralexical »

android42 wrote: post #138
KerrAvon wrote: post #122

Earlier quoted context omitted.

I think "attack" is a bit much; C++ isn't an attack on C.

I wasn't sure whether to agree with this or not, so I finally took a slightly closer look at Mojo just now. This depends on how they license it going forward, and whether they make it open, or use being a superset as a way to capture then trap python users in their ecosystem, and I don't think we have a certain answer which path they'll take yet. The way they let you mix python compatible code with their similar but…

> It looks like one of the ways they do this is by letting you define functions that only use typed variables which is something I would like to see make its way back to CPython someday (that is optionally enforcing typing in modules and getting some performance gains out of it).

This is already how Cython and MYPYC work. You add standard PEP-484 type annotations, and they use that to infer where code can be compiled to native instructions.

https://cython.readthedocs.io/en/latest/src/tutorial/pure.ht...

Re: gh-116167: Allow disabling the GIL

#193

Post by jononor »

behnamoh wrote: post #76
willcipriano wrote: post #69

Earlier quoted context omitted.

What sucked about FastAPI?

Not fast enough! I used it to call llama.cpp server but it would crash if requests were "too fast". Calling the llama.cpp server directly solved the issue.

You ran FastAPI app proper server like Uvicorn?

Re: gh-116167: Allow disabling the GIL

#195

Post by Kranar »

jononor wrote: post #189
TylerE wrote: post #175

Earlier quoted context omitted.

That's to make it thread safe without the GIL. If you only care about single thread there's all kinds of stuff you can do.

How to ensure there are no other threads, confidently enough that one can turn thread safety off?

From when I was reading the proposal, the idea is that until a C extension is loaded, you can assume that there are no other threads. Then when a module is loaded, by default you assume that it uses threads but modules that are thread free can indicate that using a flag, so if a module indicates it's thread free then you continue running without the thread safety features.

Re: gh-116167: Allow disabling the GIL

#196

Post by progmetaldev »

hn_throwaway_99 wrote: post #144
Kranar wrote: post #126

Earlier quoted context omitted.

While Ken Thompson never used the word attack, he certainly didn't have a positive opinion of the language or of Bjarne Stroustrup either in terms of his technical contributions or his handling of C++ adoption: https://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-p...

Thanks for posting that, I thought it was a great read (as someone who last used C++ probably about 25 years ago...) Given that so many of the criticisms were about C++ being over-complicated, I do worry about languages just becoming more and more difficult over time as everyone wants their pet feature added, but due to backwards-compatibility concerns old/obsolete features are rarely removed. For example, take Java.…

I haven't used Java since v1.5, roughly around 2005. I do use C# quite a bit, and have since v1.1 (I got into .NET through VB.NET at v1.0, as I had just learned VB through schooling). I look back at all the features that have been added over time, and since I have followed along as it has developed, I embrace the changes. They have made my code more concise and easier to read, with less boilerplate. When I think about someone brand new getting into the language, I truly hope they have a mentor. I can't imagine having to work with someone new to the language, and not being given plenty of time to get them up to speed with both current codebases, as well as newer ones (and I haven't even adopted the newest language versions unless it was suggested to me through Resharper, and I looked up the feature and found how it made my code easier to understand).

I feel like the comparison with Java is similar, as both Oracle and Microsoft are large corporations that largely control the language and ecosystem, while also having open source implementations. C# has made some more major changes to the language itself than Java, but both have diverged quite a bit from what they were back in 2005.

I'll find out next year, as my son goes into high school, and they are offering Java software development classes. I got Apple Basic on the Apple ][e, QuickBasic, and a bit of C++ in high school, and graduated in 1997. I wouldn't be surprised if he's going to be dealing with Java v1.5 instead of the latest features. At least I'll have a motivation to learn the latest features if he enjoys it and keeps working at it.

Re: gh-116167: Allow disabling the GIL

#197

Post by archargelod »

behnamoh wrote: post #25

I've been programming in Python for over 6 years now and every week I learn something new. But recently I've been thinking about moving to a more capable language with proper concurrency for backend API requests (FastAPI sucked). I also want types, so Elixir is not in the picture. I dabbled in Rust a bit. Although I was able to get the hang of things and build a CLI tool pretty quickly, I'm worried I'll have to deal…

You might wanna try Nim [0].

Nim is a statically-typed compiled language with very pythonic syntax. It's easy to learn, especially if you already know Python, because Nim's stdlib is heavily inspired by it.

For multithreading in Nim see:

Weave - https://github.com/mratsim/weave

Malebolgia - https://github.com/Araq/malebolgia

[0] - https://nim-lang.org

Re: gh-116167: Allow disabling the GIL

#198

Post by progmetaldev »

dimitrios1 wrote: post #151
hn_throwaway_99 wrote: post #144

Earlier quoted context omitted.

Thanks for posting that, I thought it was a great read (as someone who last used C++ probably about 25 years ago...) Given that so many of the criticisms were about C++ being over-complicated, I do worry about languages just becoming more and more difficult over time as everyone wants their pet feature added, but due to backwards-compatibility concerns old/obsolete features are rarely removed. For example, take Java.…

I was doing primarily go development since it was first released up until a few years ago when the pandemic allowed me the opportunity to move into a full time remote gig doing primarily Java development, so I can answer this as I hadn't done Java at that point for over 10 years, so I felt completely new (what Java I did before that, I was mostly trying to not use Java by using play framework or jruby on rails) As so…

I truly appreciate your answer, as someone that primarily does C#, but learned Java first back around 2003 to 2005. More so because my son is going to be learning Java next year in high school, and I know he'll be looking to me for help, and I'd like to at least be at the same language version as he's learning.

I've also been looking at Go quite a bit, especially from a lot of commentary even recently on YouTube, as well as plenty of time during work hours to experiment with languages I'm not familiar with. I've been deciding between Python and Go, and I picked up Python very quickly for the language, but ultimately I think it's the libraries and ecosystem around both that will decide it for me. Just good to see another vote for Go, especially when comparing to Java. I feel like I'm in the same boat as you seem to be, where it's all just syntax and learning frameworks, while having enough experience at this point to also pick up the smaller details while quickly being effective.

Re: gh-116167: Allow disabling the GIL

#199

Post by agent281 »

DinaCoder98 wrote: post #191
agent281 wrote: post #179

Earlier quoted context omitted.

I doubt that Python will ditch the meme. The fundamental model of dynamic dispatch using dictionaries on top of a byte code interpreter is pretty slow. I wouldn't expect it to get within 2x of JavaScript.

Javascript may not have an official bytecode, but is it not also based on the same concept of using dictionaries to dispatch code and slow as a result? I certainly had always filed it away as "about as fast as python" in my head. Why else would it rely on evented i/o?

You are correct, but they have (1) all of the money in the world as the fundamental programming language of the Internet and as a result (2) they have a state of the art tiered JIT for dynamic languages. The blood of countless PhD students flows through v8. I don't know if python will get the same treatment.

Re: gh-116167: Allow disabling the GIL

#200

Post by purpleidea »

It's neat that this will eventually improve some python code, but at the end of the day, it's still a badly typed language, which will still be slower and less safe than more modern languages.

Learn golang or rust instead. Impressive that they are managing this though!

Post reply on HN