[ChihweiLHBird]

detect_asimd only ran on little-endian aarch64. Rust's feature detection does not depend on byte order, so uucore now reports ASIMD on both.

wc is the only user of the flag, and its count path comes from bytecount, which compiles its NEON path only on little-endian targets. So wc keeps the little-endian condition, now next to that use, with a comment that says why. wc behaves the same as before on every target, so there is no new test. Related: #14821.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.

[codspeed]

Merging this PR will degrade performance by 4.85%

1 warning, 1 note

⚠️ 123 benchmarks are dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

ℹ️ 1 benchmark has no flamegraph

The flamegraph wasn't generated: most of the time was spent in runtime internals, which would leave nothing useful to analyze.

See affected benchmarks

⚡ 1 improved benchmark
❌ 1 regressed benchmark
✅ 399 untouched benchmarks
⏩ 70 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Memory	cp_recursive_deep_tree[(120, 4)]	532.6 KB	699.2 KB	-23.82%
⚡	CPU Simulation	true_consecutive_calls	350.2 ns	294.7 ns	+18.85%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing ChihweiLHBird:zhiwei/uucore-asimd-big-endian (7d24e94) with main (4939cd4)²}

Footnotes

1. 70 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (2f8b194) during the generation of this report, so 4939cd4 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.

[xtqqczze]

I'd suggest exposing detect_asimd for both little and big endian in uucore, then making changes to wc as necessary.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.

[xtqqczze]

We have the following condition:

if simd_allowed {
    bytecount::num_chars(&buf[..n])
} else {
    bytecount::naive_num_chars(&buf[..n])
};

However, bytecount::num_chars already falls back to naive_num_chars when target_endian = "little".

Given this, I think commit 3361758366318ad07717b05b16005c9627aee4b0 was actually fine.

[ChihweiLHBird]

We have the following condition:

if simd_allowed {
    bytecount::num_chars(&buf[..n])
} else {
    bytecount::naive_num_chars(&buf[..n])
};

However, bytecount::num_chars already falls back to naive_num_chars when target_endian = "little".

Given this, I think commit 3361758366318ad07717b05b16005c9627aee4b0 was actually fine.

But the original commit would make wc --debug claims ASIMD on big-endian where no NEON runs, right?

[xtqqczze]

Right, we would see something like:

$ wc --debug
debug: using hardware support (features: ASIMD)

The issue is that whether ASIMD is actually used is an implementation detail of bytecount. We may therefore want to rephrase the message to indicate that the feature is available rather than implying that it is being used.

[ChihweiLHBird]

@xtqqczze Yes, exactly. The bigger issue is that these debug messages originated in GNU. So do we want to mock GNU's behavior on the same hardware (the current way) or to reflect the real instructions set usage of uutils?

[ChihweiLHBird]

And also, for this PR, with these context, should we proceed with 3361758366318ad07717b05b16005c9627aee4b0 or the current code in the PR? Personally I prefer the latter, but I can do the former if you guys decided.

[xtqqczze]

Fuzzing failures tracked by #15567.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.

[xtqqczze]

The current wc design is really non-ideal, since we miss out on the bytecount::integer_simd implementation and fallback to a naive implementation when ASIMD is not available, but this seems fine for now.

Fundamentally the use of the bytecount crate is not really compatible with the debug: using hardware support feature as the crate decides which hardware features to use.