HackerTrans
TopNewTrendsCommentsPastAskShowJobs

colesbury

no profile record

comments

colesbury
·letztes Jahr·discuss
You don't have to build from source. uv is the best option, in my opinion, but the py-free-threading docs also have a longer list too:

uv: https://docs.astral.sh/uv/getting-started/installation/

py-free-threading: https://py-free-threading.github.io/installing-cpython/

docker: docker run -it quay.io/pypa/manylinux_2_28_x86_64 python3.13t
colesbury
·vor 2 Jahren·discuss
We could implement ownership transfer in CPython in the future, but it's a bit trickier. In Rust, "move" to transfer ownership is part of the language, but there isn't an equivalent in C or Python, so it's difficult to determine when to transfer ownership and which thread should be the new owner. We could use heuristics: we might give up or transfer ownership when putting an object in a queue.SimpleQueue, but even there it's hard to know ahead of time which thread will "get" the enqueued object.

I think the performance benefit would also be small. Many objects are only accessed by a single thread, some objects are accessed by many threads, but few objects are exclusively accessed by one thread and then exclusively accessed by a different thread.
colesbury
·vor 3 Jahren·discuss
You will always get either [1,2,3,4,5,6] or [4,5,6,1,2,3] in the upcoming `--disable-gil` builds of CPython 3.13 and the nogil forks. Most operations on mutable collections hold a per-object lock.

Part of the integration work will be to better document the thread-safety guarantees, but there is still a lot of work to do before we get there.
colesbury
·vor 3 Jahren·discuss
Memory models don't usually explicitly guarantee that writes "eventually become visible". They're usually written as ordering guarantees for when a write becomes visible, such as happens-before relationships. Obviously, for multithreaded programs to be useful, the writes have to eventually become visible to other threads/groroutines just like you want all sorts of other operations to happen in finite time that are not explicitly guaranteed by standards (like whether a thread/goroutine eventually starts.)
colesbury
·vor 3 Jahren·discuss
Go's memory model is more constrained than C, C++, and Swift and this case is specifically addressed: https://go.dev/ref/mem#restrictions.

"...each read of a single-word-sized or sub-word-sized memory location must observe a value actually written to that location"
colesbury
·vor 3 Jahren·discuss
This misses the fact that signed integer promotions are generally not free because they require sign extension. For example, the cast in b() emits a `movsx` (move with sign-extension). `movsx` is not free in the ways that `mov` can be.

`mov` can be "free" in two ways:

- the compiler can frequently avoid emitting the `mov` when part of a larger operation

- modern CPUs handle `mov` instructions earlier in the pipeline

Neither of those are true for `movsx`.