How do you know the compiler actually vectorized your loop?

The vectorization report is a per-loop verdict, and my options pricer sat at about 114 million options a second while its build log said "loop vectorized", because the loop the compiler had vectorized was a trivial one at the end of the benchmark. The pricing loop, the one full of exp and log calls, stayed scalar the whole time, with its failure notice sitting in a report I had not opened. The engine reached about 215 million only after I wrote the vector math by hand.

The report was true about the wrong loop#

The pricer is the Black-Scholes engine from the 215 million post. A clean first version priced about fifteen million options a second on one core. Swapping one modern library call for a sixty-year-old polynomial and threading the embarrassingly parallel loop took it to about 114 million, and none of that came from SIMD. The plan had always assumed the compiler would vectorize the clean inner loop on its own, because that is what the guides say, and because the build log agreed.

My compiler, MSVC, prints a line for each loop it vectorizes when asked, and my build log had one: a trivial loop at the end of the benchmark. The loop that priced options calls exp and log, and my compiler would not fold a loop full of library calls into vector form. Some toolchains will; mine did not. Its failure notice for the pricing loop sat in a report I had not opened, so the loop that mattered stayed scalar on every build while the log kept reporting a win.

The numbers carried the same tell. A four-wide vectorization can give, by itself, at most about four times on one core, and this loop, once the SIMD was real, got close to that. The jump from fifteen million to 114 million came from a better polynomial and more cores, with no SIMD in it, which is a fine speedup and a different one.

Test each vector function before wiring it in#

I wrote the exponential and the logarithm four wide, from classic polynomial cores, intrinsics all the way down. Before wiring either into the pricer I tested each one in isolation against the standard library, the exponential against the exponential rather than the pricer against the pricer. When a bug showed up, the isolated test named the function instead of leaving me to chase a wrong price three layers downstream. With real SIMD underneath, one core gained a clean four times, right at the theoretical width, and across all cores the engine reached about 215 million a second.

Three checks that catch a claimed win#

Ask the compiler for its misses. MSVC's /Qvec-report:1 prints only the loops it vectorized; /Qvec-report:2 adds the loops it declined, with a reason code. GCC's -fopt-info-vec-missed lists the missed loops, and Clang names them under -Rpass-missed=loop-vectorize and explains them under -Rpass-analysis=loop-vectorize. Then match each line to a source line and find the loop you care about. A report with only successes in it says nothing about the loop that is missing from it.

Read the width in the numbers. Vectorizing four at a time cannot, on its own, give much more than four times on one core, and a single-core gain well short of the width after a "loop vectorized" message usually has one of two causes: the loop that got vectorized was not the one doing the work, or the loop is waiting on memory rather than arithmetic. Measure one core before you measure all of them; threading hides the width.

Test the vector functions against the scalar library, one function at a time. This says nothing about what the compiler did. It checks the code you wrote to replace the compiler, over the inputs and tolerances you chose, which is the check you need the moment you stop trusting the report.

Treat the published timings as a shape#

The engine is not public and I have not re-run it for this post, so every number here is the one I published in July, and desktop timings wander ten or twenty percent run to run. Read fifteen, 114 and 215 as a shape. It was built to learn from, and none of it is a trading system. The compiler flags above are the general ones from each toolchain's documentation; MSVC's is the only one I ran on this code.

If I built the pricer again, the benchmark would carry the check itself: single-core throughput of the vector build against the scalar build on the same machine, with a floor set from repeated runs, so that a build where the width has gone missing fails on the spot instead of shipping behind a success line in the log.

---

Related:

• Pricing 215 million options a second with SIMD C++, the full climb from fifteen million to 215 million, including the memory-layout guess that came before this one
• How to backtest without fooling yourself, the same measure-before-believing discipline pointed at signals instead of speed
• Lesson 3: The check that fails, designing checks that reject a known failure