Optimize managed FastTree Sumup to native parity on arm64 - #7670
Optimize managed FastTree Sumup to native parity on arm64#7670vladimir-aubrecht wants to merge 1 commit into
Conversation
The FastTree histogram build (Sumup) uses a native SSE-free C++ library on x64/x86, but falls back to a generic managed path on arm64 (and any platform where the native library is unavailable). That fallback goes through the IIntArrayForwardIndexer interface with per-element bounds checks, making it ~1.8x slower than native and allocating per call. This adds optimized managed Sumup implementations that mirror the native templates (Sumup.h / SumupNibbles.h / SumupSegment.h) exactly, using fixed pointers and no bounds checks: - DenseIntArray: new SumupManagedDense covering 4/8/16/32-bit, weighted and unweighted, root (no doc indices) and leaf cases. Dense8/4/16/32 now dispatch the managed handler to it instead of the slow base.Sumup fallback. - SegmentIntArray: new SumupManaged mirroring SumupSegment / SumupSegment_noindices for the compressed segment format. Native remains the default on x64/x86 (UseFastTreeNative unchanged); only the managed fallback path is replaced, so arm64 picks up the fast path automatically. Because the loops iterate in the same order as native, the float accumulation is bit-identical and existing baselines are unchanged. Measured on Apple M5 (arm64): the new managed path reaches ~0.96x native throughput (parity), versus ~1.79x slower for the old fallback, with zero managed allocations per call (down from 20 B). Histogram outputs are bit-identical to the old path, and FastTree/FastForest baseline tests pass. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
@vladimir-aubrecht please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement ( “Agreement” ) is agreed to by the party signing below ( “You” ), 1. Definitions. “Code” means the computer software code, whether in human-readable or machine-executable form, “Project” means any of the projects owned or managed by .NET Foundation and offered under a license “Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any “Submission” means the Code and any other copyrightable material Submitted by You, including any 2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any 3. Originality of Work. You represent that each of Your Submissions is entirely Your 4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else 5. Licenses. a. Copyright License. You grant .NET Foundation, and those who receive the Submission directly b. Patent License. You grant .NET Foundation, and those who receive the Submission directly or c. Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement. 6. Representations and Warranties. You represent that You are legally entitled to grant the above 7. Notice to .NET Foundation. You agree to notify .NET Foundation in writing of any facts or 8. Information about Submissions. You agree that contributions to Projects and information about 9. Governing Law/Jurisdiction. This Agreement is governed by the laws of the State of Washington, and 10. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and .NET Foundation dedicates this Contribution License Agreement to the public domain according to the Creative Commons CC0 1. |
Problem
FastTree builds feature histograms via
Sumup, the per-iteration hot loop of treetraining. On x64/x86 this uses the native FastTree library; on arm64 (and any
platform where the native library isn't available) it falls back to the generic
managed
IntArray.Sumup, which goes through theIIntArrayForwardIndexerinterfacewith per-element bounds checks. That fallback is ~1.8x slower than native and
allocates on every call.
Note: the native
Sumup(Sumup.h) is itself a plain scalar loop — the only realSIMD in FastTreeNative is in
segment.cpp(one-time segment compression), not in theper-iteration histogram path. So there is no algorithmic reason managed can't match it.
Change
Add optimized managed Sumup implementations that mirror the native templates
(
Sumup.h/SumupNibbles.h/SumupSegment.h) exactly, usingfixedpointers andno bounds checks:
SumupManagedDensecovering 4/8/16/32-bit × weighted/unweighted× root (no doc indices)/leaf.
Dense8/4/16/32BitIntArraynow point their managedhandler at it instead of the slow
base.Sumup.SumupManagedmirroringSumupSegment/SumupSegment_noindicesfor the compressed segment format.Native remains the default on x64/x86 (
UseFastTreeNativeis unchanged) — only themanaged fallback path is replaced, so arm64 picks up the fast path automatically.
Because the loops iterate in the same order as native, float accumulation is
bit-identical and existing baselines are unchanged.
Results (Apple M5, arm64)
Real in-repo types (
FeatureHistogram.SumupWeighted), Dense8, weighted, 256 bins:Native comparison (native
Sumup.hscalar loop built for arm64 vs equivalent managed,N=20M): native 1337 Melem/s, old fallback 746 Melem/s (1.79x slower), new managed
1386 Melem/s (0.96x = parity). Managed allocations per call: 20 B -> 0 B.
Testing
Microsoft.ML.Predictor.Testspass onarm64 (7 passed, 0 failed; the managed path is what runs there, compared against
native-generated baselines -> confirms numerical identity).
(2000 random trials, sequential + indexed) and the 4-bit nibble formula
(5000 trials) — 0 mismatches.
Notes for reviewers
UseFastTreeNativeis intentionally left unchanged. If we later want to drop thenative library entirely, this managed path is now fast enough to be the default on
all architectures — but that is a separate decision.
Fixes #