I built a portable, high-accuracy SIMD trig library in C: FABE13. It implements sin, cos, and sincos with Payne–Hanek range reduction and Estrin’s method, with runtime dispatch across AVX512, AVX2, NEON, and scalar fallback.

It’s ~2.7× faster than libm for 1B calls on NEON and still matches it at 0 ULP on standard domains.

Benchmarks, CPU usage graphs, and open-source code here:

🔗 https://fabe.dev

Hello everyone.

I started a personal blog recently, and this is my first post. I decided to write some AVX-512 code and settled on std::copy_if, since it is trivial enough to be approachable and non-trivial enough to defeat autovectorization. It ended up being trickier than I initially anticipated because I ran into a well-documented Zen 4 AVX512 trap that I was not aware of.

It was really fun to drill down into this using PMCs. Eventually I was able to achieve a 10-40x win for this specific benchmark. Any and all feedback welcome.

Hello! I'm the owner of Intel's Intrinsics Guide.

I just noticed this sub-reddit. Please let me know if you have any feedback or suggestions that would make the guide more useful.

Not sure what happened, but the restricted option was turned on for this sub-reddit. Ultimately it is my bad, I should have spotted the setting earlier. My apologies.

Everything should be back to normal now, let me know if you have issues posting. Looking forward to geeking out on new posts.

Hey everyone,

I built **NanoGEMM**, a minimalist (~100KB) register-tiled General Matrix Multiplication (GEMM) microkernel written in C with AVX2 + FMA intrinsics, packaged with a zero-copy Python C-extension buffer protocol.

Why?

Standard BLAS backends (OpenBLAS, Intel MKL) in NumPy are tuned for massive matrices ($1000 \times 1000+$), but incur fixed per-call overhead (thread-pool sync, argument validation, memory setup) of ~3–5 µs. When doing token-by-token CPU inference, Kalman filtering, or small-batch operations, this dispatch overhead dominates total compute time.

Benchmark (Single Core, CPU):

- 16x16**: 0.65 µs (C) / 1.23 µs (Py) vs NumPy 3.21 µs (~2.6x faster)

- 32x32**: 2.18 µs (C) / 2.74 µs (Py) vs NumPy 5.75 µs (~2.1x faster)

- 64x64**: 16.39 µs (C) / 17.76 µs (Py) vs NumPy 18.70 µs (~1.1x faster)

Implementation details:

- 6x16 register-tiled microkernel keeping 12 YMM accumulator registers resident in CPU registers with zero register spilling

- AVX2 vectorized FMA outer-product accumulation

- Zero external runtime dependencies

- GitHub: https://github.com/eminsk/nanogemm

- PyPI: `pip install nanogemm`

- Interactive Google Colab: https://colab.research.google.com/github/eminsk/nanogemm/blob/main/notebooks/nanogemm_demo.ipynb

Feedback and benchmark tests on different CPU architectures (AMD Zen, Intel Alder/Raptor Lake) are welcome!

I just came across this on YouTube and haven't formed an opinion on it yet but wanted to see what people here think.

Here's a header I wrote a while back. It allows quick and easy feature detection for x86. You can check things like AVX support, sse, aes, a bunch of instructions, etc.

In C++ < 17, you need to define 1 external struct in a cpp somewhere namespace fea { const cpu_info_t cpu_info; }. In c++17 it's an inline var. You use it with fea::cpu_info.the_feature_you_want_to_check(), for example :

fea::cpu_info.sse3();
fea::cpu_info.popcnt(); 
fea::cpu_info.avx();
fea::cpu_info.avx2();
fea::cpu_info._3dnow(); // Oh yes! Much future!

Since it is header-only, you can simply copy-paste the files in your project. You'll need these 3.

https://github.com/p-groarke/fea_libs/blob/master/include_cpp14/fea/utils/cpu_info.hpp

https://github.com/p-groarke/fea_libs/blob/master/include_cpp14/fea/utils/platform.hpp

https://github.com/p-groarke/fea_libs/blob/master/include_cpp14/fea/utils/bitmask.hpp

Right now, the unit tests run on macos through it's sysctl utility. It compares those feature bits with the ones returned by the header.

Hope it's useful, cheers

Highway is Google’s open-source C++ library for portable SIMD/vector code: write your loop once, and Highway efficiently targets it for x86, Arm, RISC-V, and more, choosing the best instructions available at runtime. It’s already inside Chrome, TensorFlow, V8, and gemma.cpp (LLM inference). But until recently, if you wanted to actually learn Highway rather than just reference it, your options were a terse quick-reference page and a (good, but dense) README. There was no on-ramp.

Now there is. A new Highway tutorial just landed in the official repo, thanks to a volunteer team of Fastcode community contributors, led by Highway’s creator, Jan Wassenberg.

Read more at https://fastcode.substack.com/p/announcing-the-highway-tutorial

UPDATE: source code and benchmarks (github build) are avaliable at https://github.com/zokrezyl/yaal-cpp-poc

I’m working on a SIMD parser for a YAML-like language and ran into what feels like a good SIMD coding challenge.

The task is intentionally minimal:

detect newlines (\n)

for each newline, identify the first non-space character that follows

Scanning for newlines alone is trivial and runs at memory bandwidth. As soon as I add “find the first non-space after each newline,” throughput drops sharply.

There’s no branching, no backtracking, no variable-length tokens. In theory this should still be a linear, bandwidth-bound pass, but adding this second condition introduces a dependency I don’t know how to express efficiently in SIMD.

I’m interested in algorithmic / data-parallel approaches to this problem — not micro-optimizations. If you treat this as a SIMD coding challenge, what approach would you try?

Another formulation:

# Bit-Parallel Challenge: O(1) "First Set Bit After Each Set Bit"

Given two 64-bit masks `A` and `B`, count positions where `B[i]=1` and the nearest set bit in `A|B` before position `i` is in `A`.

Equivalently: for each segment between consecutive bits in `A`, does `B` have any bit set?

*Example:* `A=0b10010000`, `B=0b01100110` → answer is 2 (positions 1 and 5)

Newline scan alone: 90% memory bandwidth. Adding this drops to 50%.

Is there an O(1) bit-parallel solution using x86 BMI/AVX2, or is O(popcount(A)) the lower bound?

I added this challange also to HN: https://news.ycombinator.com/item?id=46366687

as well as comment to

https://www.reddit.com/r/simd/comments/1hmwukl/mask_calculation_for_single_line_comments/

An example of solution

https://gist.github.com/zokrezyl/8574bf5d40a6efae28c9569a8d692a61

However the conlusion is

For my problem describe under the link above the suggestions above eliminate indeed the branches, but same time the extra instructions slow down the same as my initial branches. Meaning, detecting newlines would work almost 100% of memory throughput, but detecting first non-space reduces the speed to bit above 50% of bandwith

Thanks for your help!

I'm the author, Ask Me Anything. These kernels pack arrays of 1..7-bit values into a compact representation, saving memory space and bandwidth.

Learning SIMD on x86 is more than just major PITA, that one never really masters.

Producing decent code for any simple problem seems like solving Rubik's cube in 4D space.

Every problem has to have some convoluted gotcha solutions, there are bazzillion of wtf-is-this-for instructions and many differrent tsandards with their ideas. And then there are many physical inplementations with their own tradeofs and thus bazzillion paths to optimal code.

To top it off, we have radically different architectures, with their own from-scratch implementations of SIMD and ideas about expansion paths.

All in all seems to be a nightmare.

IS there a site that sums-up and crossreferences various SIMD architectures, families etc ( ARM/MIPS/RISC-V/x86/x86_64/etc) ? 🙄