Repository navigation
sort/argsort/topk ties: libstdc++ order on Linux (#81, stacked on #82) - #92
Merged
Merged
Conversation
…inux wheel does (#81) Upstream's manylinux torch 2.13.0 is built with GCC 13.3.1 (the .comment of libtorch_cpu.so, same on aarch64 and x86_64), so its unstable sort, partial sort and nth_element are libstdc++'s introsort (threshold 16), heap select and introselect, not libc++'s. libstdcxx_sort.rs transcribes GCC 13.3's stl_algo.h / stl_heap.h with libcxx_sort.rs's API; UPSTREAMS_STD selects libc++ on Apple/Android, libstdc++ on linux-gnu, and the stable order elsewhere (Windows/MSVC stays the other half of #81). Oracle: gen_sortties_oracle.py run in Docker on linux/arm64 and linux/amd64 gave byte-identical files -> tests/ops/sortties_oracle_linux.json (22728 cells, 8542 differ from the libc++ oracle). The transcription agrees on 22168 of 22168 non-error cells (Python reference and the Rust compiled alone). test_sortties.py compares against it on Linux instead of skipping; the golden strict tie check applies on Linux again. Nullified: S_THRESHOLD 16 -> 15 drops agreement to 18445 of 22168 and fails all_equal_17_is_libstdcxx_order. Here (macOS): test_sortties 14/14, cargo test libstdcxx 5/5, golden self-test PASS. The Linux shim side is proven only by Linux CI.
PR #92's x86_64 CI: argsort of eighty ties now answers [50, 59, ...] like upstream, because the shim runs libstdc++'s introsort there. The test compared it with upstream's *stable* order whenever upstream's default was not index order; it now compares default with default wherever a runtime is transcribed (darwin, linux) and keeps the stable reference elsewhere.
Contributor
Gate on CI (issue #24)Full gate: 132 suites = 124 run on at least one CI runner + 8 local-only. The local gate (
Local-only: verified by no CI runner (8)
Suites that verified nothing, or failed, on a runner
Every suite, every runner
A SKIP is unverified on that runner, never passed. UNVERIFIED means the suite ran and every one of its tests skipped by name. |
3 tasks
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
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.
Refs #81 (Linux half; MSVC/Windows remains). Stacked on #82 (#33): merge it first.
Feature added:
libstdcxx_sort.rs, a transcription of GCC 13.3 libstdc++std::sort/partial_sort/nth_element(upstream's manylinux wheel:GCC 13.3.1per libtorch_cpu.so .comment), selected on linux-gnu.Test added: Linux oracle
tests/ops/sortties_oracle_linux.jsonmeasured from upstream torch 2.13.0 in Docker on linux/arm64 and linux/amd64 (byte-identical; 8542 of 22728 cells differ from libc++).test_sortties.pyuses it on Linux instead of skipping; golden strict tie check back on Linux; 5 Rust unit tests.Evidence: transcription agrees 22168/22168 non-error cells (Python reference and the Rust compiled alone). Nullified: threshold 16 -> 15 gives 18445/22168. macOS unchanged: test_sortties 14/14, golden self-test PASS. The Linux shim path is proven only by this PR's Linux CI.