Łukasz Langa

If your thread is waiting on a blocking network connection, it also does not need to hold the lock because that particular moment in time, there is not going to be any Python code executing. So you can give that gill to somebody else. So there are special cases in which we were already sort of parallel more than not. But it is very implicit.

If your thread is waiting on a blocking network connection, it also does not need to hold the lock because that particular moment in time, there is not going to be any Python code executing. So you can give that gill to somebody else. So there are special cases in which we were already sort of parallel more than not. But it is very implicit.

It depends on us carefully finding all those special cases and enabling them. And in the end, it does not scale for regular user applications. So if you just write Python code that loops over things and just executes some string concatenations, all these regular things that you expect from a Python program, most of the time you're not going to be seeing any parallelism there.

It depends on us carefully finding all those special cases and enabling them. And in the end, it does not scale for regular user applications. So if you just write Python code that loops over things and just executes some string concatenations, all these regular things that you expect from a Python program, most of the time you're not going to be seeing any parallelism there.

Yes, well, like, it depends. It depends, yes. It's a factor. Tell me why. Right. So first of all, the speed of Python is mostly affected by the fact that it does a ton of indirection. The thing that costs the most in computer science, say for bad algorithms, is indirection.

Yes, well, like, it depends. It depends, yes. It's a factor. Tell me why. Right. So first of all, the speed of Python is mostly affected by the fact that it does a ton of indirection. The thing that costs the most in computer science, say for bad algorithms, is indirection.

So every time where some language can just point at memory, read a value, and it's done, it's going to be faster than a language that, well, actually everything is dynamic. So you point at a value, but then that value has another value. So you have to go somewhere else in memory to read another value, then decide what to do. and read yet another value.

So every time where some language can just point at memory, read a value, and it's done, it's going to be faster than a language that, well, actually everything is dynamic. So you point at a value, but then that value has another value. So you have to go somewhere else in memory to read another value, then decide what to do. and read yet another value.

So every time in Python that you're accessing an attribute, you're executing a ton of code compared to accessing a field in a struct in C. So that's going to be the main factor of it being slow. But the way where Gale is hampering us is scalability, which means simply for things that you could parallelize, you cannot do that effectively.

So every time in Python that you're accessing an attribute, you're executing a ton of code compared to accessing a field in a struct in C. So that's going to be the main factor of it being slow. But the way where Gale is hampering us is scalability, which means simply for things that you could parallelize, you cannot do that effectively.

So this is where the reputation of not really scalable comes in. But ironically, the GIL also makes Python faster than it would be without it. The reason why is because reference counting is a major reason for the global interpreter lock's existence. But it's not the only reason you need a lock in your interpreter.

So this is where the reputation of not really scalable comes in. But ironically, the GIL also makes Python faster than it would be without it. The reason why is because reference counting is a major reason for the global interpreter lock's existence. But it's not the only reason you need a lock in your interpreter.

There's going to be internal data structures like dictionaries where if you insert another key that wasn't there before, maybe there's going to be some rehashing that happens, right? So suddenly the simple operation is going to take a little more time than usual. So there's going to be a time, a split second where the internal structure of the dictionary is inconsistent, right?

There's going to be internal data structures like dictionaries where if you insert another key that wasn't there before, maybe there's going to be some rehashing that happens, right? So suddenly the simple operation is going to take a little more time than usual. So there's going to be a time, a split second where the internal structure of the dictionary is inconsistent, right?

For example, you would be able to see that it has more elements in terms of count than you actually are able to access or you're going to be trying to access an element that is there. It claims it's there, but you cannot get it yet because the dictionary is being mutated, right?

For example, you would be able to see that it has more elements in terms of count than you actually are able to access or you're going to be trying to access an element that is there. It claims it's there, but you cannot get it yet because the dictionary is being mutated, right?

So for all those things, and there's plenty of cases like that, the global rapid log is very convenient because we are already holding it because we care about the reference counts to be always correct. So there's no other lock we need to care about. And this is actually making matters cheaper because we only have this one. And once you hold it, you can just run and it's great.

So for all those things, and there's plenty of cases like that, the global rapid log is very convenient because we are already holding it because we care about the reference counts to be always correct. So there's no other lock we need to care about. And this is actually making matters cheaper because we only have this one. And once you hold it, you can just run and it's great.

And plenty of authors of C extensions like NumPy and so on can also depend on the fact that as soon as you have the golden number lock, you have a lock that you can yourself depend on for your own synchronization needs. So now, without that, you're going to have to have fine-grained locking. So for every of those use cases that require synchronization, you're going to have to have a smaller lock.

And plenty of authors of C extensions like NumPy and so on can also depend on the fact that as soon as you have the golden number lock, you have a lock that you can yourself depend on for your own synchronization needs. So now, without that, you're going to have to have fine-grained locking. So for every of those use cases that require synchronization, you're going to have to have a smaller lock.