ojph 0.10.2: Highway fat-binary fork with runtime dispatch - #41
Merged
Merged
Conversation
<details><summary>Claude's draft</summary> Bump the vendored fork to 1.1.0 (the consolidated Highway series: foreach_target fat binary SSE4.1/AVX2/AVX3/AVX3_DL/AVX3_SPR selected at run time, width-portable HT encoder, irv97 recovery, rev53 audit fixes, clang-cl toolchain support on the fork side). The kernels now dispatch through the Google Highway library at run time, so headers alone no longer suffice. tools/build_openjph.py uses an installed libhwy when present (conda; the extension then links the shared library) and otherwise downloads Highway 1.4.0 and builds a static archive that setup.py links into the extension alongside libojph, keeping wheels fully self-contained. setup.py picks whichever of the two the install prefix provides, and only links -lhwy when a libhwy actually exists (OJPH_ALLOW_NO_HWY builds keep linking). Windows wheels intentionally keep the cl.exe toolchain (static-AVX2 hwy, unchanged behavior); the fork's clang-cl support enables the full dispatch ladder there later if wanted. Verified locally: wheel-style path (no conda) downloads and builds static hwy, extension is self-contained (ldd clean) and contains the N_SSE4/N_AVX2/N_AVX3/N_AVX3_DL/N_AVX3_SPR target namespaces; conda path links shared libhwy; 186 tests pass on both; mask perf on this AVX2 machine unchanged (rev12 5.04/4.44 ms enc/dec). Resume this Claude session: ``` cd /home/mark/git/jp2k claude --resume 487c1e20-36f3-416f-8be1-437c25ed67fe ``` </details>
<details><summary>Claude's draft</summary> Fork 1.1.1 fixes the Highway usability probe (AppleClang defaults to a pre-C++11 standard; the probe now pins C++17) and scopes OJPH_REQUIRE_HWY to x86, where the hwy kernels exist. ARM targets (macOS arm64, linux aarch64, windows ARM64) build the generic kernels as they always have, instead of failing configure; macOS x86_64 gains the full fat binary. Resume this Claude session: ``` cd /home/mark/git/jp2k claude --resume 487c1e20-36f3-416f-8be1-437c25ed67fe ``` </details>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prepared by Mark Harfouche's Claude bot; Mark Harfouche (@hmaarrfk) reviews via the GitHub interface.
Bumps the vendored fork to ojph-1.1.0 — the consolidated Highway series. What users get:
Build mechanics: the kernels dispatch through the Highway library now, so
tools/build_openjph.pybuilds a static libhwy when downloading (wheels stay fully self-contained — verifiedldd-clean with all target namespaces present) and links the environment's shared libhwy in conda/dev setups. Windows wheels deliberately keep the cl.exe/static-AVX2 build (unchanged behavior).Release plan: merge on green CI, tag
0.10.2.https://claude.ai/code/session_015rdawfurPCmefzjoeFfuC4