Add contrib intdiv: fast integer division by invariant scalars using multiplication by abhishek-iitmadras · Pull Request #2875 · google/highway

abhishek-iitmadras · 2026-02-23T16:30:40Z

This change adds a contrib module implementing fast integer division by invariant (loop-constant) divisors using multiplication and shifts, following Granlund & Montgomery, “Division by Invariant Integers Using Multiplication” (PLDI 1994).

Supports all scalar lane widths and signs:
- Unsigned: uint8_t, uint16_t, uint32_t, uint64_t
- Signed: int8_t, int16_t, int32_t, int64_t
This contrib module provides general-purpose, cross-architecture implementation of division by invariant scalars using multiplication, suitable for vectorized code built on Highway. It mirrors the GM(Algo) scheme and is conceptually similar to the integer SIMD division intrinsics used in NumPy’s npyv_intdiv, but expressed purely in Highway’s portable SIMD API.

Benchmarking Script : https://gist.github.com/abhishek-iitmadras/169f995df2bf9b1e7827c712528af0c2

jan-wassenberg

A bunch of comments :) Some influence others, so please read them all before addressing any.

jan-wassenberg · 2026-02-25T18:34:15Z

+ *
+ * We split the work into two steps:
+ *   1) Precompute parameters from the scalar divisor (multiplier + shifts).
+ *  DivisorParams{U,S}<T> ComputeDivisorParams(T divisor);


Can we reuse any of the existing logic from base.h Divisor[64]?

OK, good to use pre-exist API so:

now reuse the existing Divisor64 128-bit division primitive instead of duplicating it in our intdiv-inl.h

But to work correct we need to do chnage in base.h is to make Divisor64::Div128 public in the HWY_HAVE_DIV128 implementation [Currently it is private]. Then only intdiv-inl.h can call: hwy::Divisor64::Div128(high, divisor).

Also keep the full DivisorParamsU / DivisorParamsS logic in intdiv-inl.h because Divisor / Divisor64 do not cover signed params, 8/16-bit widening params, pow2 metadata, divisor storage for remainder, or floor-division correction. But the 128-bit high-half division primitive should definitely be shared.

jan-wassenberg · 2026-02-25T18:36:27Z

+};
+
+template <>
+struct MulType<uint8_t> {


We can use existing functionality: base.h also has

template <> struct Relations<uint8_t> { using Unsigned = uint8_t; using Signed = int8_t; using Wide = uint16_t; };

etc, so we could use MulType = Relations::Wide.

I tried but it partially applicable but not a direct replacement as mapping diverge for 32-bit and 64-bit

See : #2875 (comment)

jan-wassenberg · 2026-02-25T18:52:30Z

+  return HWY_NAMESPACE::ComputeDivisorParams<T>(d);
+}
+
+template <typename T, HWY_IF_T_SIZE(T, 1), HWY_IF_SIGNED(T)>


Rather than SFINAE for T size 1..8, we can HWY_IF_T_SIZE_ONE_OF(T, (1 << 1) | (1 << 2) | (1 << 4) | (1 << 8)), or better yet, just static_assert IsPow2(sizeof(T)) within one function.

ok got it , now collapse repeated size-based SFINAE overloads into single signed and unsigned overload using static_assert for supported integer sizes

jan-wassenberg · 2026-02-25T18:53:44Z

+  return HWY_NAMESPACE::ComputeDivisorParams<T>(d);
+}
+
+template <class D, class V = VecD<D>, typename T = TFromD_<D>, HWY_IF_UNSIGNED_D(D)>


Here also we could static_assert(IsUnsigned()) inside the function, given that you have a DivisorParamsU argument.

same here also

jan-wassenberg · 2026-02-25T18:56:02Z

+  if constexpr (sizeof(T) <= 4) {
+    return static_cast<T>(Random32(&rng));
+  } else {
+    const uint64_t hi = Random32(&rng);


We do have a Random64().

Thanks
Done , i have used Random64() now

jan-wassenberg · 2026-02-25T18:56:30Z

+}
+
+template <typename T>
+bool IsPow2(T x) {


Already defined in intdiv-inl.h?

DOne, Removed from here

jan-wassenberg · 2026-03-16T17:09:28Z

+
+template <>
+struct MultiplierType<uint32_t> {
+  using type = uint32_t;


We can use using type = If<(sizeof(T) < 4), Relations::Wide, T>.

As per your suggestion , i agree with reusing the existing Highway type relation, but i don't think If<(sizeof(T) < 4), MakeWide<T>, T> is safe here.

SO Looking at hwy/base.h, Relations<int64_t> has no Wide member (only Unsigned/Signed/Float/Narrow), so MakeWide<int64_t> is ill-formed.

SO And if i am not wrong then the main issue is that the type arguments to If still have to be well-formed before selection.
SO For int64_t, MakeWide<int64_t> is ill-formed because Relations<int64_t> does not define Wide. so even though sizeof(int64_t) < 4 is false, the expression still fails during substitution.

The partial specialization keeps the selection lazy:

template <typename T, bool kNeedsWiden = (sizeof(T) < 4)> struct MultiplierType { using type = T; }; template <typename T> struct MultiplierType<T, true> { using type = MakeWide<T>; };

Now this still reuses Highway's MakeWide<T> / Relations<T>::Wide for 8- and 16-bit types, but avoids instantiating MakeWide<T> for 32- and 64-bit types. That is also intentional because the 32/64-bit paths use same-width multiplier storage and have separate MulHigh / Div128 handling.

Correct me if i am wrong

Signed-off-by: Abhishek Kumar <abhishek.r.kumar@fujitsu.com>

abhishek-iitmadras · 2026-05-12T11:34:32Z

Hi @jan-wassenberg

Benchmarking script : https://gist.github.com/abhishek-iitmadras/169f995df2bf9b1e7827c712528af0c2

Machine Detail : https://instances.vantage.sh/aws/ec2/c7g.metal?currency=USD (SVE_256 Machine)

Benchmarks were run on Arm SVE-256. The divisor is supplied via Google Benchmark arguments (state.range(1)), so it is a runtime divisor, not a compile-time constant. IntDivHot precomputes divisor parameters once from that runtime divisor and reuses them across the array.

Measured sizes:

Expression	N
`1 << 10`	1,024
`1 << 14`	16,384
`1 << 18`	262,144
`1 << 20`	1,048,576

Runtime divisor sets:

Type	Divisors
`uint8_t`	`1, 2, 3, 255, 254`
`uint16_t`	`1, 2, 3, 65535, 65534`
`uint32_t`	`1, 2, 3, 4294967295, 4294967294`
`uint64_t`	`1, 2, 3, 9223372036854775807, 9223372036854775806`
`int8_t`	`1, 2, 3, -1, -2, -3, 127, 126`
`int16_t`	`1, 2, 3, -1, -2, -3, 32767, 32766`
`int32_t`	`1, 2, 3, -1, -2, -3, 2147483647, 2147483646`
`int64_t`	`1, 2, 3, -1, -2, -3, 9223372036854775807, 9223372036854775806`

Result :

Table below reports N = 1,048,576 and divisor = 3 because it is a representative non-power-of-two runtime divisor and shows steady-state throughput. Similar speedups were observed across the other measured N and divisor combinations; full raw benchmark logs are linked below.

All result numbers are in ns

Type	Scalar Div	hwy::Div	IntDiv hot	Div Speedup vs Scalar	Div Speedup vs hwy::Div	Scalar Rem	Hwy::Mod	IntRem hot	Rem Speedup vs Scalar	Rem Speedup vs Hwy::Mod
uint8_t	2420803	354136	110614	21.89x	3.20x	2824895	354777	124355	22.72x	2.85x
uint16_t	3181084	354224	222489	14.30x	1.59x	3590825	354230	250584	14.33x	1.41x
uint32_t	404994	405026	156150	2.59x	2.59x	5201766	405090	182853	28.45x	2.22x
uint64_t	1416638	1416703	376722	3.76x	3.76x	8453969	1416804	453290	18.65x	3.13x
int8_t	354220	364346	133731	2.65x	2.72x	2821562	365327	152098	18.55x	2.40x
int16_t	354205	354713	268272	1.32x	1.32x	3531486	354317	304257	11.61x	1.16x
int32_t	405057	405025	209654	1.93x	1.93x	5148002	405842	234037	22.00x	1.73x
int64_t	1412837	1410457	457177	3.09x	3.09x	8384109	1410448	539478	15.54x	2.61x

Raw benchmark logs

Type	Log
`int8_t`	`sve256_int8.txt`
`int16_t`	`sve256_int16.txt`
`int32_t`	`sve256_int32.txt`
`int64_t`	`sve256_int64.txt`
`uint8_t`	`sve256_uint8.txt`
`uint16_t`	`sve256_uint16.txt`
`uint32_t`	`sve256_uint32.txt`
`uint64_t`	`sve256_uint64.txt`

abhishek-iitmadras · 2026-05-12T13:04:48Z

little detail about benchmarking script : https://gist.github.com/abhishek-iitmadras/169f995df2bf9b1e7827c712528af0c2

Benchmark	What it measures	Divisor handling	Purpose
`BM_ScalarDivAutoVec<T>`	Plain C++ scalar loop using `/`	Runtime divisor from `state.range(1)`	Baseline for normal C++ division. Auto-vectorization is allowed.
`BM_HwyDiv<T>`	Existing Highway `hn::Div(v, divv)`	Runtime divisor broadcast with `hn::Set(d, divisor)`	Baseline for existing generic Highway vector division.
`BM_IntDivHot<T>`	New `hn::IntDiv(d, v, params)` path	Runtime divisor; `ComputeDivisorParams` is done once outside the timed loop	Main benchmark for intended invariant-divisor use case.
`BM_IntDivCold<T>`	New `hn::IntDiv(d, v, params)` path including setup	Runtime divisor; `ComputeDivisorParams` is done inside the timed loop	Measures cost when divisor parameters are not precomputed ahead of time.
`BM_IntDivMixedDivisors<T>`	New `hn::IntDiv` with different precomputed params per vector chunk	Params are precomputed; timed loop only selects among them	Branch-stress benchmark for `params.is_pow2` behavior.
`BM_ScalarRemAutoVec<T>`	Plain C++ scalar loop using `%`	Runtime divisor from `state.range(1)`	Baseline for normal C++ remainder. Auto-vectorization is allowed.
`BM_HwyMod<T>`	Existing Highway `hn::Mod(v, divv)`	Runtime divisor broadcast with `hn::Set(d, divisor)`	Baseline for existing generic Highway vector remainder.
`BM_IntRemHot<T>`	Remainder via `q = IntDiv(...)`, then `r = a - q * divisor`	Runtime divisor; params are precomputed outside timed loop	Measures new invariant-divisor remainder path.
`BM_ScalarFloorDivAutoVec<T>`	Scalar signed floor division using Python/NumPy semantics	Runtime divisor from `state.range(1)`	Baseline for signed floor division. Signed types only.
`BM_IntFloorDivHot<T>`	New vectorized signed floor division via `hn::IntDivFloor`	Runtime divisor; params are precomputed outside timed loop	Measures vectorized Python/NumPy-style floor division. Signed types only.
`BM_ComputeParams<T>`	Only `hn::ComputeDivisorParams(divisor)`	Runtime divisor from `state.range(0)`	Measures divisor-parameter precomputation cost alone.
`BM_HwyBaseDivisorU32`	Scalar `hwy::Divisor` from `hwy/base.h`	Runtime `uint32_t` divisor; scalar precomputed helper	Optional comparison against existing scalar unsigned 32-bit helper. Not registered by default.
`BM_HwyBaseDivisorU64`	Scalar `hwy::Divisor64` from `hwy/base.h`	Runtime `uint64_t` divisor; scalar precomputed helper	Optional comparison against existing scalar unsigned 64-bit helper. Not registered by default.
`BM_ScalarDivInPlace<T>`	In-place scalar array division	Runtime divisor from `state.range(1)`	Baseline for in-place array API.
`BM_IntDivArrayInPlace<T>`	In-place array division using `hn::DivideArrayByScalar`	Runtime divisor; params are computed inside array helper	Measures end-to-end array API performance.

jan-wassenberg · 2026-05-15T14:58:43Z

+
+      constexpr int kShift = static_cast<int>(sizeof(T) * 8);
+
+#if defined(HWY_HAVE_ORDEREDDEMOTE2TO)


What's the issue here? I'd think/hope this is always available. What are the circumstances when it isn't? Can we remove the #if?

What's the issue here? I'd think/hope this is always available. What are the circumstances when it isn't? Can we remove the #if?

Thanks , you are right

I confused myself — #if is to false everywhere and every build has been silently going through the Combine + DemoteTo fallback path.

As per the docs, OrderedDemote2To is available whenever HWY_TARGET != HWY_SCALAR.

But i already did if constexpr (D::kPrivateLanes < 2) already routes HWY_SCALAR (and any other single-lane tag) to ScalarDivPerLane, so by the time we reach this line we're guaranteed to be on a target where OrderedDemote2To exists.

So the answer to "when isn't it available?" is: only on HWY_SCALAR, which can't reach this code path anyway.

SO i am removing the #if and calling OrderedDemote2To unconditionally in both the signed and unsigned IntDiv branches.

I guess numbers should improve slightly since they'll now actually hit the optimized demote path.
Thanks again to point out this

jan-wassenberg

I'll be out from Sat to May26, so let's try to land this first and address the #if and branch later.

abhishek-iitmadras · 2026-05-15T20:12:35Z

Sorry , @jan-wassenberg
look like new commit push revert your stale review decision , please proceed again with this 😊 which also trigger two import/copybara CI's

jan-wassenberg reviewed Feb 23, 2026

View reviewed changes

Comment thread BUILD Outdated

jan-wassenberg requested changes Feb 25, 2026

View reviewed changes

abhishek-iitmadras force-pushed the abhishekk_intdiv branch from 9b1a2f6 to d728618 Compare March 16, 2026 16:11

abhishek-iitmadras marked this pull request as ready for review March 16, 2026 16:13

jan-wassenberg reviewed Mar 16, 2026

View reviewed changes

rageshh-fj force-pushed the abhishekk_intdiv branch from d728618 to 44c3e62 Compare April 29, 2026 10:50

abhishek-iitmadras force-pushed the abhishekk_intdiv branch from 44c3e62 to 964a47d Compare May 1, 2026 08:34

add intdiv imp

78b390e

Signed-off-by: Abhishek Kumar <abhishek.r.kumar@fujitsu.com>

abhishek-iitmadras force-pushed the abhishekk_intdiv branch from 964a47d to 78b390e Compare May 3, 2026 14:05

abhishek-iitmadras requested a review from jan-wassenberg May 12, 2026 12:18

jan-wassenberg reviewed May 15, 2026

View reviewed changes

jan-wassenberg previously approved these changes May 15, 2026

View reviewed changes

jan-wassenberg added the ready to pull label May 15, 2026

Simplify OrderedDemote2To usage in intdiv-inl.h

780c897

abhishek-iitmadras dismissed jan-wassenberg’s stale review via 780c897 May 15, 2026 20:00


		constexpr int kShift = static_cast<int>(sizeof(T) * 8);

		#if defined(HWY_HAVE_ORDEREDDEMOTE2TO)

Conversation

abhishek-iitmadras commented Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

jan-wassenberg left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

abhishek-iitmadras May 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

abhishek-iitmadras Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

abhishek-iitmadras Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

abhishek-iitmadras May 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

abhishek-iitmadras commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Result :

Raw benchmark logs

Uh oh!

abhishek-iitmadras commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jan-wassenberg left a comment

Choose a reason for hiding this comment

Uh oh!

abhishek-iitmadras commented May 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

abhishek-iitmadras commented Feb 23, 2026 •

edited

Loading

abhishek-iitmadras May 3, 2026 •

edited

Loading

abhishek-iitmadras Mar 16, 2026 •

edited

Loading

abhishek-iitmadras Mar 16, 2026 •

edited

Loading

abhishek-iitmadras May 2, 2026 •

edited

Loading

abhishek-iitmadras commented May 12, 2026 •

edited

Loading

abhishek-iitmadras commented May 12, 2026 •

edited

Loading