Hacker News Reader

Comment by Animats | Hacker News Reader

Well, yes. It's a naive interpreter. The source is translated to the obvious bytecode. At run time, everything is a CObject, including integers and floats. Everything which you'd expect to be a dict really is a dict. So you spend a lot of run time checking the types of objects, dispatching, and looking up variables. There's a bit of memoization, I think, to cut down some of the lookups.

It's tough to optimize a language where any thread can change the internal variables of any other thread at any time. Python has gratuitous dynamism. Rarely does code muck with the state of another thread, but it can, and the code has to handle the worst case. There's no such thing as a thread-local variable in Python.

View on HN

> any thread can change the internal variables of any other thread at any time

Why is this different from Java, where the JVM can assume that local variables cannot be changed by other threads?

That is, in the absence of special cases, which I believe include `volatile` and function calls. (Any other special cases?)

Am I missing something, or does your first question answer itself? The question asserts a specific difference. (I don't remember how it works in Java to know if the assertion is correct.)

As I understand it, the JVM can assume that local variables are not modified by other threads. My question is why can't CPython make the same assumption?

Because it's not true! Threads in Python can muck around with the state of any other thread, at any time – it would be a language change to assume otherwise.

What op means is that it’s not true in Java as well, but the JVM assumes it is true until detecting otherwise

And some of the optimizations that do exist are interesting. I wonder if, post-Spectre/Meltdown, the old side channel results involving Python's integer behavior would be more widely viewed as problematic.

I'm not sure which "side channel results" you refer to, but I don't think Python tries to prevent Spectre-style attacks at all. I don't believe it's necessary because, unlike JavaScript and Lua, Python doesn't try to support running within an in-process sandbox.

They seem to have been pretty well known among my former co-workers so I'm not sure if there's an original paper on it or what, but things like detecting the difference between small (cached) integer creation time and the full object instantiation, computational complexity attacks on dictionaries, etc.

These are distinct from eg Spectre because the point isn't isolation breaking, it's leakage. But at least a few years ago there was always a question of "are side channel attacks real", and I think we're pretty clearly over that question now.

There is threading.local.

https://docs.python.org/3/library/threading.html

That's a package to create a namespace. The compiler doesn't know you're doing that. Nor are those variables really thread-local. You can pass a reference to them to another thread.

How is what you've said not applicable to C/C++?

You can easily pass the address of a thread_local variable around. Threads can easily muck around with objects from multiple threads. Hell that's even true with Java too.

The reason threading is weird on Python is due to the GIL. Optimizing for threads is tough because Python explicitly avoids defining a threading model & assumes all implementations have something like the GIL. That doesn't mean no optimization is possible.

One big difference is the c/c++ standards say that messing with a variable in multiple threads without locks is undefined behaviour, while Python claims there at least won't be an interpreter crash.

I fail to see how what you said is relevant. All you've said is that Python & C/C++'s memory models are different from each other, which yes they are & no one has stated otherwise. My interpretation of the claims made were:

1. Python doesn't have thread-local variables 2. Python's memory model around threading is what prevents any optimization.

Both are clearly incorrect. For example, take Java. You have the same behaviour as Python: your VM won't crash & your code won't even generate a panic. Java clearly has thread-local variables & an optimizing compiler.

Python's inhibition around optimizing is partially around the guarantees they make around APIs that do self introspection but mainly around keeping the interpreter simple. For a counterpoint see PyPy, Cython, JPython, IronPython etc which optimize Python just fine. They mostly trip over module extensions being tied directly to the non-standardized CPython module API & that API is tied intimately to implementation decisions of CPython.

Right. The options in this area are:

- Don't check. Programs will crash if a thread-local variable is passed outside the thread (C, C++)

- Naive interpreter. Everything works, slowly, because the worst case code is used for everything. (CPython)

- Really clever just-in-time recompilation when what seemed to be thread-local suddenly gets accessed from another thread. (PyPy, Java?)

- Compile time checking to prevent this. (Rust)

- No threads (classic Javascript)

- Explicit shared areas into which only certain types can be placed (ECMAscript 2018)

there is essentially no such thing as threads in python, unless I am completely missing something.

The default python interpreter does absolutely nothing to make it's execution thread-safe, and that appears to be a deliberate decision on their part to keep the complexity of the interpreter down.

On the contrary, the Global Interpreter Lock provides many thread-safety guarantees. These are based on the fact that threads can only be interrupted between, not within, byte code instructions.

For example, a single list can safely be extended (as in `l += [1]`) concurrently from several threads.

Ah, you are correct, it's the non-threadedness of the interpreter itself I was thinking of.

On the contrary. For example, each python thread you create results in the creation of a POSIX thread in the interpreter, when you're running CPython on Linux.

The GIL just means that only one of those threads will be executing pure-Python code at any time. But they're still normal threads.

If you want to details about the GIL and Python threads, this is a nice presentation:

http://www.dabeaz.com/python/UnderstandingGIL.pdf

Reply on news.ycombinator.com