Skip to content

ENH: use c11 atomics for numpy#30489

Merged
ngoldbaum merged 4 commits into
numpy:mainfrom
kumaraditya303:stdatomics
Dec 24, 2025
Merged

ENH: use c11 atomics for numpy#30489
ngoldbaum merged 4 commits into
numpy:mainfrom
kumaraditya303:stdatomics

Conversation

@kumaraditya303
Copy link
Copy Markdown
Contributor

@kumaraditya303 kumaraditya303 commented Dec 20, 2025

Experiment: use c11 atomics for numpy instead of hand-written atomic functions.

@github-actions github-actions Bot added the 36 - Build Build related PR label Dec 20, 2025
@kumaraditya303 kumaraditya303 changed the title BLD: use c11 atomics for numpy ENH: use c11 atomics for numpy Dec 20, 2025
@kumaraditya303 kumaraditya303 marked this pull request as ready for review December 22, 2025 12:09
@kumaraditya303
Copy link
Copy Markdown
Contributor Author

cc @rgommers @ngoldbaum

Copy link
Copy Markdown
Member

@ngoldbaum ngoldbaum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice simplification. I agree that relaxed loads should be fine - in the worst case there will be some blocking or duplication of work in code paths for cache misses.

Just to be extra sure, I wrote a little test script which doesn't produce any race reports on a TSan-instrumented build of 3.14:

import numpy as np
from numpy.testing._private.utils import run_threaded


dt = np.dtype(('i4', [('a', '<i2'), ('b', '<i2')]))


def worker(b):
    b.wait()
    hash(dt)


run_threaded(worker, 500, pass_barrier=True)

I'd like someone else who knows numpy's build infrastructure on Windows to weigh in about the new experimental build flag.

Comment thread meson.build
Copy link
Copy Markdown
Member

@rgommers rgommers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, this is worth trying indeed.

The /experimental:c11atomics was added in VS 2022 version 17.5 Preview 2, which I believe corresponds to toolchain version 19.35. Right now the minimum we support is 19.20, so before merging we should bump that version number on line 28 of the top-level meson.build file to 19.35. That way we'll get a clear error message if the installed compiler is too old.

Once that is changed, this LGTM I think.

@kumaraditya303
Copy link
Copy Markdown
Contributor Author

Once that is changed, this LGTM I think.

I have updated the msvc version.

@ngoldbaum
Copy link
Copy Markdown
Member

It occurs to me: let's add a release note for the MSVC minimum version bump too.

@kumaraditya303
Copy link
Copy Markdown
Contributor Author

let's add a release note for the MSVC minimum version bump too.

Where do I need to add it? I am not familar with how numpy handles release notes.

@mattip
Copy link
Copy Markdown
Member

mattip commented Dec 23, 2025

See the README.rst and other examples in doc/release/upcoming_changes

@kumaraditya303
Copy link
Copy Markdown
Contributor Author

Thanks, I added it to the release notes

@ngoldbaum
Copy link
Copy Markdown
Member

ngoldbaum commented Dec 24, 2025

CI failures are due to transient network issues during the docs build and are unrelated. Let’s merge this and we’ll see if anyone running against our main branch reports issues.

@ngoldbaum ngoldbaum merged commit 7e6f606 into numpy:main Dec 24, 2025
73 of 75 checks passed
@kumaraditya303 kumaraditya303 deleted the stdatomics branch December 24, 2025 15:13
@ngoldbaum ngoldbaum added the 39 - free-threading PRs and issues related to support for free-threading CPython (a.k.a. no-GIL, PEP 703) label Jan 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

36 - Build Build related PR 39 - free-threading PRs and issues related to support for free-threading CPython (a.k.a. no-GIL, PEP 703)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants