# Why does the SIMD path use \< instead of \<= in std.mem.findScalarPos?

**URL:** <https://ziggit.dev/t/why-does-the-simd-path-use-instead-of-in-std-mem-findscalarpos/17267>\
**Category:** Help\
**Tags:** standard-library\
**Created:** [August 16, 2026, 6:23pm UTC](https://ziggit.dev/t/why-does-the-simd-path-use-instead-of-in-std-mem-findscalarpos/17267 "2026-08-16T18:23:55Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![noobie](https://ziggit.dev/letter_avatar_proxy/v4/letter/n/d78d45/32.png) [@noobie](https://ziggit.dev/u/noobie)\
**Post date:** [August 16, 2026, 6:23pm UTC](https://ziggit.dev/t/why-does-the-simd-path-use-instead-of-in-std-mem-findscalarpos/17267/1 "2026-08-16T18:23:55Z")

</div>

I’m trying to understand the reasoning behind the `<` checks in this SIMD code.

The relevant part is:

```zig
if (i + 2 * block_len < slice.len) {
    const mask: Block = @splat(value);
    while (true) {
        inline for (0..2) |_| {
            const block: Block = slice[i..][0..block_len].*;
            const matches = block == mask;
            if (@reduce(.Or, matches)) {
                return i + std.simd.firstTrue(matches).?;
            }
            i += block_len;
        }
        if (i + 2 * block_len >= slice.len) break;
    }
}

```

Then the tail handling has:

```zig
const block_x_len = block_len / (1 << j);

if (i + block_x_len < slice.len) {
    const block: BlockX = slice[i..][0..block_x_len].*;
    ...
}

```

I’m wondering why these use `<` instead of `<=`.

If a block ends exactly at `slice.len`, wouldn’t it still be valid? For example, if `slice.len == 16` and `block_len == 8`, the block `[8..16)` fits completely.

With `<`, that final block is left for the scalar loop instead.

I’m mainly trying to understand if there is a performance, bounds-check, or other implementation reason for using `<` here that I’m missing.

---

<div class="post-metadata">

**Author:** ![Eisenhauer](https://ziggit.dev/letter_avatar_proxy/v4/letter/e/76d3ee/32.png) [@Eisenhauer](https://ziggit.dev/u/Eisenhauer)\
**Post date:** [August 16, 2026, 6:35pm UTC](https://ziggit.dev/t/why-does-the-simd-path-use-instead-of-in-std-mem-findscalarpos/17267/2 "2026-08-16T18:35:15Z")

</div>

Looks to me like the usual difference between Offset (`i`) and Size (`slice.len`). There is a nice visualization at TigerBeetles Blog post [Index, Count, Offset, Size](https://tigerbeetle.com/blog/2026-02-16-index-count-offset-size/)

I think the use of `<` is appropriate here.

---

<div class="post-metadata">

**Author:** ![noobie](https://ziggit.dev/letter_avatar_proxy/v4/letter/n/d78d45/32.png) [@noobie](https://ziggit.dev/u/noobie)\
**Post date:** [August 16, 2026, 7:08pm UTC](https://ziggit.dev/t/why-does-the-simd-path-use-instead-of-in-std-mem-findscalarpos/17267/3 "2026-08-16T19:08:22Z")

</div>

I see the index/count distinction, but in this case I think `i + block_len` is an end position rather than an index. If `i = 8` , `block_len = 8` , and `slice.len = 16` , the accessed range is `[8..16)` , so the block fits exactly. That’s why I’m wondering why the condition uses `<` rather than `<=` .

---

<div class="post-metadata">

**Author:** ![Eisenhauer](https://ziggit.dev/letter_avatar_proxy/v4/letter/e/76d3ee/32.png) [@Eisenhauer](https://ziggit.dev/u/Eisenhauer)\
**Post date:** [August 16, 2026, 9:28pm UTC](https://ziggit.dev/t/why-does-the-simd-path-use-instead-of-in-std-mem-findscalarpos/17267/4 "2026-08-16T21:28:51Z")

</div>

Sorry, I didn’t read your question carefully enough. Now I follow your reasoning. From an intuitive perspective, I see no performance benefit in always leaving work for the scalar tail loop. For properly sized slice lengths, I’d expect one more iteration of the SIMD loop to be faster.

---

<div class="post-metadata">

**Author:** ![squeek502](https://ziggit.dev/user_avatar/ziggit.dev/squeek502/32/409_2.png) [@squeek502](https://ziggit.dev/u/squeek502)\
**Post date:** [August 17, 2026, 4:26am UTC](https://ziggit.dev/t/why-does-the-simd-path-use-instead-of-in-std-mem-findscalarpos/17267/5 "2026-08-17T04:26:39Z")

</div>

I think you’re right that there’s no reason for this/it’s a mistake. Feel free to submit a PR if you’re up for it.

(bonus points if you are willing to check for the same mistake in other `std.mem` functions)