Refactor CPU feature detection to use an explicit x86 whitelist

[ihb2032]

Currently, cpu_features.cc assumes that any architecture that is not __ARM_ARCH must be an x86/x64 architecture and attempts to include <cpuid.h>. This causes fatal compilation errors on other architectures like RISC-V.
Changes Proposed
This PR refactors the preprocessor directives to use an explicit "whitelist" approach:

• <cpuid.h> and x86-specific CPUID logic are now only compiled when x86_64 or i386 is explicitly defined or under MSVC for Windows.
• All other architectures including ARM, RISC-V, etc. will safely fall back to the default initialization, allowing the project to compile successfully as generic C++ code.

Motivation
This resolves build failures on RISC-V environments and sets up a clean, safe foundation for potentially adding architecture-specific optimizations in the future.
closed #244

[greptile-apps]

Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.

[richyreachy]

hi @ihb2032, as we noticed that RISC-V is available on github runner (#244), could you please setup a CI job on it along with this PR?

[richyreachy]

@ihb2032 please take a look at this error: https://github.com/alibaba/zvec/actions/runs/24500696519/job/71607486150

Seems the ci job can be brought up after Github App was setup.

Any problem, let me know.

[ihb2032]

Hi @richyreachy, thanks for pointing that out!

I checked the logs and the issue is that actions/setup-python currently doesn't provide a pre-built Python 3.10 binary for the riscv64 architecture on Ubuntu 24.04.

To fix this without breaking the other builds that share 03-macos-linux-build.yml, I've updated the workflow to conditionally use Python 3.12 only when inputs.platform == 'linux-riscv64', while keeping the rest on 3.10.

I've just pushed the fix, let's see if the CI turns green!

[ihb2032]

Hi @richyreachy, the RISC-V CI failed due to a timeout. Would it be possible to split the build and test phases to prevent this?

[richyreachy]

Hi @richyreachy, the RISC-V CI failed due to a timeout. Would it be possible to split the build and test phases to prevent this?

There's hard timeout limit(6 hours ) for CI jobs. Since test stage depends on the outcome of build, it may need some effects to figure out how to shrink the process.

[ihb2032]

Hi @richyreachy,
To address the timeout while keeping the workflow stable, I'm thinking of a targeted optimization for the RISC-V build.
We could update the workflow to use the wheel provided by RISE for the cmake package, but only when the platform is linux-riscv64. For all other architectures, we’ll continue to use the standard packages from PyPI to ensure no regressions.
According to my estimate, this change could shave off nearly 1 hour from the RISC-V CI job. Does this conditional approach sound good to you?

[richyreachy]

Hi @richyreachy,

To address the timeout while keeping the workflow stable, I'm thinking of a targeted optimization for the RISC-V build.

We could update the workflow to use the wheel provided by RISE for the cmake package, but only when the platform is linux-riscv64. For all other architectures, we’ll continue to use the standard packages from PyPI to ensure no regressions.

According to my estimate, this change could shave off nearly 1 hour from the RISC-V CI job. Does this conditional approach sound good to you?

Yes. The workflow for RISC-V is slower compared to other architectures. Every measurement deserves a try for execution time optimization.

[ihb2032]

@richyreachy Good news is that all the other RISC-V tests have passed. As I pointed out earlier, the C++ test failure is just down to the hnsw_streamer_test case.

Glad to hear it! Could @iaojnh please take a look at the streamer test failure? To my knowledge, it should already be resolved.

Here's the fix: #375

[ihb2032]

@richyreachy Looks like the remaining C++ test failure is still stemming from hnsw_streamer_test.

[ihb2032]

@richyreachy @iaojnh It looks like the CI is still failing on hnsw_streamer_test. Could you take another look?

[ihb2032]

Hi @iaojnh, FYI, the linux-riscv64 C++ CI is failing on HnswStreamerTest.TestKnnSearchCosine due to a borderline recall assertion.

[richyreachy]

hi @ihb2032 can you use cache by following this commit? d91867e

[richyreachy]

hi @ihb2032

Good news that all runtime errors have been fixed!

As we discussed internally, since the workflow runs quite slowly, it would be more efficient to run this CI job nightly instead. Here’s an example for reference:
https://github.com/alibaba/zvec/blob/main/.github/workflows/nightly_coverage.yml

Any problem or concern, please let me know.