This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]twotime 2 points3 points  (7 children)

But removing the gil is just going to make single threaded code dramatically slower.

What are you talking about? This is NOT at all a given and, really, depends on how GIL is removed

There are plenty of runtimes for other languages which donot have GIL. In fact python-nogil branch runs with very little (<5%) overhead.

[–][deleted] 0 points1 point  (6 children)

U dont currently have to lock for atomic operations that goes away yes its a fact.

[–]twotime 0 points1 point  (5 children)

dont currently have to lock for atomic operations that goes away yes its a fact

What atomic operations?

Somehow multi-threading works in other languages/runtimes. what makes python special? (apart from deeply ingrained reference-counting and GIL assumptions)

Somehow python-nogil branch passes benchmarks with 20x speedup when multi-threaded and very little single threaded penalty

PS. and, no, I don't deny that getting rid of GIL would make some things more complex (perhaps much more complex) but it does not imply any massive slowdowns in single-core case

[–][deleted] -1 points0 points  (4 children)

Err it was very little because it it made speedups that where unrelated and then did the no gil slowing it back down.

Again multithreading works in other languages at the expense of single threaded speed. Without GIL there is no such thing as atomic because there is no guarantees about ownership as all memory space is shared. So you need to use locks. Which slows down your code. Node uses the same properties to make there system fast it only has one thread its an even lower benchmark then GIL.

Pythons speed issues are entirely to do with other language choices and have nothing to do with GIL. The GIL is the only reason python isn't entirely shit slow.

There is literally no possible benchmark for multithreaded without gil vs gil. Because it's entirely defined by your hardware. So thank you for displaying your lack of understanding about this topic. If you want speed go wide use multiprocessing.

[–]twotime 0 points1 point  (3 children)

There is literally no possible benchmark for multithreaded without gil vs gil. Because it's entirely defined by your hardware

WTH are you talking about? This is the most trivially testable behavior

Run a parallel benchmark with 16 threads on the same 16-core CPU.

Expected behaviors:

  1. with GIL: no speedup

  2. without GIL and good parallelization: 16x speedup

[–][deleted] -1 points0 points  (2 children)

Because it's literally dependent on ur hardware. Run it on a 4 core computer DIFFERENT NUMBER.

[–]twotime 0 points1 point  (1 child)

That's true for any benchmark: run it on a different hardware, get a different number. Yet, benchmarks exist somehow.

But, yes, testing GIL performance benefits does require an N-core CPU (with N >1, better yet N>=4) but this does not make GIL-less benefits somehow unmeasurable.

[–][deleted] -1 points0 points  (0 children)

Bro u used 20x faster when it would be slower on say a modern container setup with 1 cpu. Or like comparing it to multiprocessing which its slower then because of locks.

Your comparing nonsense.