Note thatnpy_ucs4 is four bytes and fnv-1a operates on octets of data (e.g. individual bytes).

The reference implementation takes avoid * pointer and immediately casts it tounsigned char *. You could do similar.

We could also add the reference implementation as a vendored dependency (e.g. a git submodule). The license is compatible.

Thanks for the suggestion.
If we go the submodule route for lcn2/fnv, where in the NumPy tree would you like the submodule to live? Let me know your preferred path and I’ll add it accordingly.

Vendoring would work for me as well (e.g. copying a single header the way stlab does inadobe/fnv.hpp).
If we go with a vendored file instead of a submodule, which path in the NumPy tree would you prefer for it to live?

I would probably vendor it as a git submodule innumpy/_core/src/common, next topythoncapi-compat. Maybe take a look at the PR addingpythoncapi-compat as a vendered dependency to see how that header-only vendored dependency is integrated into the numpy build system.

I only have a slight preference for a git submodule, since it makes updating the vendored code marginally easier. If you feel like it's easier to structure it as just a copy/pasted new header file (that includes a note about the original copyright and license), I'd probably just put that header innumpy/_core/src/multiarray.

Tried the submodule approach, but ran into two blockers:

• the reference source expects to be built with a plainmake step that is not available on every platform/toolchain we target.
• the code still uses legacy BSD typedefs such asu_int32_t; that builds fine on Linux/macOS but fails to compile on WASM, Windows/Clang, etc.

Because of these two issues the submodule route looks impractical for NumPy at the moment.

Fair enough, thanks for checking. Vendoring a somewhat adapted version makes sense.

I’ve re-implemented the FNV-1a hash function based on the reference implementation fromlcn2/fnv, with appropriate modifications. To keep the scope and visibility of the function well-managed, I split the implementation into a header and a .c source file.

After this change, the benchmarked runtime improved slightly from 35.1 sec to 33.5 sec.

I think you need to explicitly set an error indicator with e.g.npy_gil_error.NpyString_load doesn't do it for you.

Added the error indicator PyErr_SetString in the failure branch

if (is_null == -1) {PyErr_SetString(PyExc_RuntimeError,"Failed to load string from packed static string.");returnNULL;        }

you need to have the GIL acquired before you call this - that’s why I suggestednpy_gil_error, since it handles that dance

Thank you for pointing this out.
SwitchedPyErr_SetString tonpy_gil_error.