fix: 64-bit randint could return high; correct the integer fills by vchamarthi · Pull Request #172 · IntelPython/mkl_random

vchamarthi · 2026-09-04T04:02:35Z

What

Four fixes in the integer fills, all in mkl_distributions.cpp.

1. randint could return high. In the masked branch of the 64-bit fill,
rng was incremented before the mask was derived from it:

rng = hi - lo;
rng++;                      /* now a count, not a maximum */
mask = smear_bits(rng);     /* one bit too wide */
if (value <= rng) accept;   /* admits lo + rng, which is hi + 1 */

Fixed by leaving rng as the inclusive maximum and using rng + 1 only where
viRngUniform wants an exclusive bound.

The same surplus mask bit also forced roughly half of all draws to be rejected
and redrawn whenever rng + 1 was a power of two. With the mask correct,
mask == rng means nothing can be rejected, so those requests now fill the
result buffer directly.

2. The integer fills handled at most two MKL_INT_MAX chunks. They used
if where the other 43 chunking sites in the same file use while, so a larger
request recursed once, fell through, and passed a count that overflows MKL's
32-bit int. NDEBUG compiles out the assert, so the error was swallowed and
the tail was never written.

3. multinomial decremented its chunk counter by elements, not draws
(len -= k * MKL_INT_MAX), skipping work and leaving the tail of large outputs
unwritten.

4. The fills narrower than int staged the whole request. viRngUniform
only emits 32-bit integers, so a uint8 fill allocated four bytes per element
to produce one, then read that buffer back to narrow it: 40 MB allocated to
write 10 MB of output. Now staged one cache-resident tile at a time.

Numbers

Xeon Gold 6338, single thread, ns/element, min of 2 runs. Intel-channel
mkl / mkl-devel 2026.1.0-intel_236, meson build. Baseline and patched
installed in separate conda envs.

case	before	after
`uint64`, power-of-two range 2**32	25.4	1.39	18.3x
`uint64`, power-of-two range 2**48	25.4	1.39	18.3x
`uint64`, `iinfo.max` upper bound	9.69	1.93	5.0x
`bool`, 10M	3.85	1.11	3.4x
`uint8`, 10M	3.79	1.11	3.4x
`uint16`, 10M	3.93	1.12	3.5x
`uint32`, 10M (control)	1.90	1.89	unchanged

Streams change

Only power-of-two ranges at or above INT_MAX change, and only because the old
mask there was wrong. Of 12 seeded outputs compared, exactly one hash moved:
randint(0, 2**32, dtype='uint64'). The other 11 are bit-identical, including
every narrow dtype, uint32, standard_normal and multinomial. The
narrow-int tiling is bit-identical by construction: a VSL stream is sequential,
so tiling draws the same values in the same order.

Testing

Suite: 190 -> 209 passed, 3 skipped. The 19 new tests also pass on unpatched
master, so they are invariant guards rather than fitted to this change.
Out-of-range scan on unpatched master, randint(0, 2**31), 8e9 draws per
dtype: 3 hits on default int, 3 on int64, 2 on uint64. After the fix, 0
on all three.
Verified on upstream master 6b7962f.

Notes for reviewers

test_randint_in_bounds_fuzz only uses high in {4, 8, 16}, all of which
take the 32-bit path, so the masked 64-bit branch had no coverage. The new
test covers ranges at and above INT_MAX.
The out-of-range failure fires about once per 2**32 draws, so the added test
asserts the bound invariant rather than trying to reproduce it.
Fixes 2 and 3 are reasoned from the source, not reproduced: they need requests
above two MKL_INT_MAX chunks (~4.4 GB for bool, ~26 GB for
multinomial). Worth a second opinion on whether the while conversion is
correct in all eight fills.
irk_discrete_uniform_long_vec already derived its mask from the inclusive
maximum, which is the pattern this restores in the 64-bit fill.

ndgrigorian · 2026-09-04T07:09:43Z

@vlad-perevezentsev
Is this also fixed in #168 ? Or separate?

vlad-perevezentsev · 2026-09-04T09:51:16Z

@vlad-perevezentsev Is this also fixed in #168 ? Or separate?

Looks separate
irk_rand_uint32_vec/irk_rand_uint64_vec still call viRngUniformBits32/64 (and this PR adds one more viRngUniformBits64 call in mask == rng branch)
For WH/MCG31/R250/MRG32K3A those return -1014 so the full-range scalar draw is still broken for these BRNGs

antonwolfy · 2026-09-04T11:11:12Z

    }
 }

 void irk_rand_uint64_vec(irk_state *state,


There is near-twin irk_discrete_uniform_long_vec (used by randint_untyped) keeps the old single-path rejection loop and the pre-fix VSL_RNG_METHOD_UNIFORM_STD constant.
It'd be nice to research on performance improvement there also in the follow-up PR.

…er-fills

ndgrigorian · 2026-09-04T17:13:25Z

@vlad-perevezentsev Is this also fixed in #168 ? Or separate?

Looks separate irk_rand_uint32_vec/irk_rand_uint64_vec still call viRngUniformBits32/64 (and this PR adds one more viRngUniformBits64 call in mask == rng branch) For WH/MCG31/R250/MRG32K3A those return -1014 so the full-range scalar draw is still broken for these BRNGs

Can you @vchamarthi work with @vlad-perevezentsev to fix the full-range scalar draw also for the other BRNGs?

vlad-perevezentsev · 2026-09-07T09:57:22Z

@vlad-perevezentsev Is this also fixed in #168 ? Or separate?

Looks separate irk_rand_uint32_vec/irk_rand_uint64_vec still call viRngUniformBits32/64 (and this PR adds one more viRngUniformBits64 call in mask == rng branch) For WH/MCG31/R250/MRG32K3A those return -1014 so the full-range scalar draw is still broken for these BRNGs

Can you @vchamarthi work with @vlad-perevezentsev to fix the full-range scalar draw also for the other BRNGs?

I will fix this in the next PR after merging this one

vlad-perevezentsev

LGTM
Thank you @vchamarthi
Just a few minor points

vlad-perevezentsev · 2026-09-14T13:57:09Z

+    )
+    def test_narrow_width_full_range_in_bounds(self, dtype):
+        # Narrow fills stage in tiles; cover the 4096 tile boundary and beyond.
+        hi = 2 if dtype == "bool" else int(np.iinfo(dtype).max)


Suggested change

hi = 2 if dtype == "bool" else int(np.iinfo(dtype).max)

hi = 2 if dtype == "bool" else int(np.iinfo(dtype).max + 1)

to cover the full range

vlad-perevezentsev · 2026-09-14T13:59:20Z

+        # Ranges at or above INT_MAX take the masked branch, which
+        # test_in_bounds_fuzz never reaches (it only uses high <= 16).
+        for dtype in ("int64", "uint64"):
+            if low + high > np.iinfo(dtype).max:


Suggested change

if low + high > np.iinfo(dtype).max:

if high > np.iinfo(dtype).max + 1:

vlad-perevezentsev · 2026-09-14T14:30:30Z

@@ -1808,18 +1809,7 @@ void irk_rand_uint8_vec(irk_state *state,
    }

    assert(lo < hi);


looks identical in all five narrow fills so they can move into irk_rand_narrow_fill
note:
lo is an int there so the fill needs a cast

if (lo == hi) { DIST_PRAGMA_VECTOR for (i = 0; i < len; ++i) res[i] = (T)lo; return; } assert(lo < hi);

Then if (len < 1) above on 1800 line looks redundant because the constant fill and while (len > 0)already do nothing forlen <= 0`

For irk_rand_bool_vec the remaining assert((lo == 0) && (hi == 1)) can either stay or go.
Once lo == hi is handled inside the helper assert(lo < hi) already implies it for npy_bool
If you keep it it has to become assert((lo == hi) || ((lo == 0) && (hi == 1))) because it is now reachable for lo == hi as well

fix: derive the 64-bit randint mask from the range maximum

d53e103

vchamarthi requested review from antonwolfy, jharlow-intel, ndgrigorian, vlad-perevezentsev and xaleryb as code owners September 4, 2026 04:02

antonwolfy added this to the 1.6.0 release milestone Sep 4, 2026

antonwolfy reviewed Sep 4, 2026

View reviewed changes

vlad-perevezentsev reviewed Sep 4, 2026

View reviewed changes

Comment thread CHANGELOG.md Outdated

vlad-perevezentsev reviewed Sep 4, 2026

View reviewed changes

Comment thread mkl_random/src/mkl_distributions.cpp

vchamarthi added 2 commits September 4, 2026 09:24

fix pr suggestions

02033af

Merge remote-tracking branch 'upstream/master' into fix/randint-integ…

adc5356

…er-fills

Merge branch 'master' into fix/randint-integer-fills

519be4d

vlad-perevezentsev approved these changes Sep 14, 2026

View reviewed changes

Navigation Menu

Uh oh!

fix: 64-bit randint could return high; correct the integer fills - #172

fix: 64-bit randint could return high; correct the integer fills#172
vchamarthi wants to merge 4 commits into
IntelPython:masterfrom
vchamarthi:fix/randint-integer-fills

vchamarthi commented Sep 4, 2026

Uh oh!

ndgrigorian commented Sep 4, 2026

Uh oh!

vlad-perevezentsev commented Sep 4, 2026

Uh oh!

Uh oh!

antonwolfy Sep 4, 2026

Uh oh!

Uh oh!

Uh oh!

ndgrigorian commented Sep 4, 2026

Uh oh!

vlad-perevezentsev commented Sep 7, 2026

Uh oh!

vlad-perevezentsev left a comment •

edited

Loading

Uh oh!

vlad-perevezentsev Sep 14, 2026

Uh oh!

vlad-perevezentsev Sep 14, 2026

Uh oh!

vlad-perevezentsev Sep 14, 2026

Uh oh!

vlad-perevezentsev Sep 14, 2026

Uh oh!

vlad-perevezentsev Sep 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

	hi = 2 if dtype == "bool" else int(np.iinfo(dtype).max)
	hi = 2 if dtype == "bool" else int(np.iinfo(dtype).max + 1)

	if low + high > np.iinfo(dtype).max:
	if high > np.iinfo(dtype).max + 1:

		@@ -1808,18 +1809,7 @@ void irk_rand_uint8_vec(irk_state *state,
		}

		assert(lo < hi);

Uh oh!

Conversation

vchamarthi commented Sep 4, 2026

What

Numbers

Streams change

Testing

Notes for reviewers

Uh oh!

ndgrigorian commented Sep 4, 2026

Uh oh!

vlad-perevezentsev commented Sep 4, 2026

Uh oh!

Uh oh!

antonwolfy Sep 4, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ndgrigorian commented Sep 4, 2026

Uh oh!

vlad-perevezentsev commented Sep 7, 2026

Uh oh!

vlad-perevezentsev left a comment • 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!

vlad-perevezentsev Sep 14, 2026

Choose a reason for hiding this comment

Uh oh!

vlad-perevezentsev Sep 14, 2026

Choose a reason for hiding this comment

Uh oh!

vlad-perevezentsev Sep 14, 2026

Choose a reason for hiding this comment

Uh oh!

vlad-perevezentsev Sep 14, 2026

Choose a reason for hiding this comment

Uh oh!

vlad-perevezentsev Sep 14, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

vlad-perevezentsev left a comment •

edited

Loading