google
highway
C++2020–2026
google / highway
highway
Performance-portable, length-agnostic SIMD with runtime dispatch
37Distinct people
107Mentions
1Explicit recommenders
6KGitHub stars
What to know before exploring
What it is
Performance-portable, length-agnostic SIMD with runtime dispatch
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
> but that algorithm requires costly preprocessing of the set to be matched. For string functions, input strings are usually very short > the advantage of longer vectors…
janwas used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- simd-everywhere/simde · linked in 2 of the same discussions
- vcdevel/std-simd · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year107 dated mentions
Observed mentions: 2020-08-04 18:38:08 UTC to 2026-09-25 20:11:25 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 24 | 1 | 23 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 30 | 1 | 29 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 18 | 2 | 16 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 13 | 0 | 13 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 12 | 2 | 10 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Efficient and performance-portable vector software
Highway is a C++ library that provides portable SIMD/vector intrinsics.
Documentation
Previously licensed under Apache 2, now dual-licensed as Apache 2 / BSD-3.
Why
We are passionate about high-performance software. We see major untapped
potential in CPUs (servers, mobile, desktops). Highway is for engineers who want
to reliably and economically push the boundaries of what is possible in
software.
How
CPUs provide SIMD/vector instructions that apply the same operation to multiple
data items. This can reduce energy usage e.g. fivefold because fewer
instructions are executed. We also often see 5-10x speedups.
Highway makes SIMD/vector programming practical and workable according to these
guiding principles:
Does what you expect: Highway is a C++ library with carefully-chosen
functions that map well to CPU instructions without extensive compiler
transformations. The resulting code is more predictable and robust to code
changes/compiler updates than autovectorization.
Works on widely-used platforms: Highway supports seven architectures; the
same application code can target various instruction sets, including those with
'scalable' vectors (size unknown at compile time). Highway only requires C++17
(language features, not necessarily the library) and supports four families of
compilers. If you want to use Highway on other platforms, please raise an issue.
Flexible to deploy: Applications using Highway can run on heterogeneous
clouds or client devices, choosing the best available instruction set at
runtime. Alternatively, developers may choose to target a single instruction set
without any runtime overhead. In both cases, the application code is the same
except for swapping HWY_STATIC_DISPATCH with HWY_DYNAMIC_DISPATCH plus one
line of code. See also @kfjahnke's
introduction to dispatching.
Suitable for a variety of domains: Highway provides an extensive set of
operations, used for image processing (floating-point), compression, video
analysis, linear algebra, cryptography, sorting and random generation. We
recognise that new use-cases may require additional ops and are happy to add
them where it makes sense (e.g. no performance cliffs on some architectures). If
you would like to discuss, please file an issue.
Rewards data-parallel design: Highway provides tools such as Gather,
MaskedLoad, and FixedTag to enable speedups for legacy data structures. However,
the biggest gains are unlocked by designing algorithms and data structures for
scalable vectors. Helpful techniques include batching, structure-of-array
layouts, and aligned/padded allocations.
We recommend these resources for getting started:
SIMD programming with Highway talk
SIMD for C++ Developers
Algorithms for Modern Hardware
Optimizing software in C++
Improving performance with SIMD intrinsics in three use cases
Examples
Online demos using Compiler Explorer:
multiple targets with dynamic dispatch
(more complicated, but flexible and uses best available SIMD)
single target using -m flags
(simpler, but requires/only uses the instruction set enabled by compiler
flags)
We have prepared several tutorial-like examples in hwy/examples; see the
README.md there for more information.
Basics:
sum_array_advanced.cc: 4x unrolling and remainder handling.
dot_product_unroll.cc: similar to sum_array_advanced, plus reduction.
matrix_transpose_scatter_gather: shows/compares Scatter and Gather.
Infrastructure:
benchmark.cc: dot product with remainder-free loops and benchmarking.
profiler_example: shows how to use the our built-in profiler for measuring
the time cost of annotated zones.
skeleton*: a complete example of a module with runtime dispatch.
Challenges:
masks_and_logic.cc: visualizes masks/comparisons with ASCII art.
ctf_aes.cc: capture the flag, brute-force AES password guessing.
We observe that Highway is referenced in the following open source projects,
found via sourcegraph.com. Most are GitHub repositories. If you would like to
add your project or link to it directly, feel free to raise an issue or contact
us via the below email.
Audio: Zimtohrli perceptual metric
Browsers: Chromium (+Vivaldi), Firefox (+floorp / foxhound / librewolf /
Waterfox)
Computational biology: RNA analysis,
long-sequence preprocessing
Computer graphics: ghostty-org/ghostty,
Sparse voxel renderer,
tgfx 2D Graphics library
Cryptography: google/distributed_point_functions, google/shell-encryption
Data structures: bkille/BitLib
Image codecs: eustas/2im,
Grok JPEG 2000,
JPEG XL,
JPEGenc,
Jpegli,
libaom,
OpenHTJ2K
Image processing: awxkee/aire, cloudinary/ssimulacra2,
libvips, m-ab-s/media-autobuild_suite,
Image viewers: AlienCowEatCake/ImageViewer, diffractor/diffractor,
Lux panorama/image viewer,
mirillis/jpegxl-wic
Information retrieval:
iresearch database index,
michaeljclark/zvec,
nebula interactive analytics / OLAP,
ScaNN Scalable Nearest Neighbors,
Machine learning: array2d/deepx,
gemma.cpp, Tensorflow, Numpy,
zpye/SimpleInfer
Programming languages:
AOT-compiled python, oven-sh/bun, V8/V8,
yinqiwen/rapidudf
Robotics:
MIT Model-Based Design and Verification
Vector search: 1yefuwang1/vectorlite, vespa-engine/vespa
Other
Evaluation of C++ SIMD Libraries:
"Highway excelled with a strong performance across multiple SIMD extensions
[..]. Thus, Highway may currently be the most suitable SIMD library for many
software projects."
zimt: C++11 template library to process n-dimensional arrays with multi-threaded SIMD code
vectorized Quicksort (paper)
Highway can also be installed via a package manager or from a repository:
Click to expand BSD repositories
DragonFlyBSD
FreeBSD
GhostBSD
MidnightBSD
Click to expand cross platform package repositories
conan-io
conda-forge
EasyBuild
Homebrew
microsoft/vcpkg
spack
xmake-io/xmake-repo
Click to expand linux package repositories
Obtained from repology
Click to expand Windows package repositories
fd00/yacp
MSYS2
Click to expand other operating
Read the full README on GitHubWhat Hacker News says
107 sourcesWe recently published another: https://github.com/google/highway/blob/master/g3doc/tutorial...
In Platform-independent SIMD in GoWould anyone be able to compare this library's design to https://github.com/google/highway?
In Fearless SIMD v1.0I would love to have an open source Rust SIMD library with the scope and maturity that
https://github.com/google/highway brings to C++.
In Rust SIMD on the GPU> How is that different from any other compiler optimization?
When it can be single-handedly responsible for an 8× speedup, you might not want to rely as much on the compiler as in the case of smaller, cumulative optimisations.
> And what is the alternative? Handroll manual SIMD code for every possible architecture you may target?
Use a library like Highway? https://github.com/google/highway
In Everyone should know SIMDThere is some discussion of the possible options here: https://github.com/google/highway#strip-mining-loops
In Everyone should know SIMDwe make extensive use of simd at work, usually through highway: https://github.com/google/highway
imo this is one of the greatest libs ever written. it handles dynamic dispatching of correct simd instructions / lane widths for various hardware with just one simd loop written (handling NEON/AVX/AVX2/AVX512/extensions) with comparable performance to handwritten native intrinsics
In Everyone should know SIMD> mitchell, i know you hang around some of these comments sometimes
hi im here
> i noticed that in ghostty you bring in some c++ libs to do the simd heavy lifting for you. any plans to port that to zig? anything missing from the language or libs that's preventing it?
No plans to port it. For others, this is referencing highway: https://github.com/google/highway
The major limitation of Zig's vectors is that they're compile-time only. So if you're building redistributed software that compiles for a baseline CPU target, it won't be as optimized as it could be for YOUR possible machine.
Highway compiles our SIMD modules for different hardware configurations and at startup does a CPUID fingerprint to figure out which to load. That way even baseline has AVX512 etc. implementations, and we just activate the right one at runtime.
We only use High
Read the rest
way for our hottest hot paths that we feel benefit from that specialization.
No plans to port that (although, I spent hundreds of dollars and slop-forked it into Zig with the help of this good boy GPT and it worked great actually, but I didn't want to maintain it).
We recommend Highway over std::simd
4 points · Open discussionWe recommend Highway over std:SIMD
6 points · Open discussionPeople reported challenges building V8 (whether upstream or the Node.js variant) on s390x with z13 support. I don't know if it was discussed on the porters mailing list because it's not public: https://groups.google.com/g/v8-s390-ports
Elsewhere, some people interpreted https://github.com/google/highway/issues/1895 as meaning that Highway code does not work on z13 at all.
In C++26 Shipped a SIMD Library Nobody Asked ForLooks like the ratification plan for Zvzip is November. So maybe 3y until HW is actually usable?
That's a neat trick with wmacc, congrats. But still, half the speed for quite a fundamental operation that has been heavily used in other ISAs for 20+ years :(
Great that you did a gap analysis [1]. I'm curious if one of the inputs for that was the list of Highway ops [2]?
[1]: https://gist.github.com/camel-cdr/99a41367d6529f390d25e36ca3...
[2]: https://github.com/google/highway/blob/master/g3doc/quick_re...
In RISC-V Is SloooowAs someone who used std::simd in an attempt for submitting to an academic conference CFP*, I have look deep into how std::simd and I would conclude that there are a couple of reasons it isn't stable yet (this is rather long and maybe need 10 minutes to read):
1. It is highly depending on LLVM intrinsics which itself can change quite a lot. Sometimes the intrinsic would even fail to instantiate and crashed the entire compilation. I for example met chronic ICE crashes for the same code in different nightly Rust version. Then I realize it is because the SIMD operation was too complicated and I need to simplify it, and sometimes need to stop recursing and expanding too much to prevent stack spilling and exhausting register allocation.
This happens from time to time especially when using std::simd with embedded target where registers are scarc
Read the rest
ity.
2. Some hardware design decisions making SIMD itself not ergonomic and hard to generalize, this is also reflected on the design of std::simd as well.
Recall that SIMD techniques stems from vector processors in supercomputers from the likes of Cray and IBM, that is from the 70s and back then computation and hardware design was primitive and simple, so they have fixed vector size.
The ancient design is very stable, and is still kept till this day, even with the likes of AVX2, AVX512, VFP and NEON, so this influenced the design of things like lane count (https://doc.rust-lang.org/std/simd/struct.LaneCount.html).
But the plot twist: as time goes on, it turns out that modern SIMD is now capable of doing variable sizes; RISC-V's SIMD extension is one such implementation for example.
So now we come to a dilemma on to keep the existing fixed lane count design, or allow it to extend further. If we allow it to extend further to cater for things like variable-SIMD vector length, then we need to wait for generic_const_exprs to be stable, and right now it is not only not stable but incomplete too (https://github.com/rust-lang/portable-simd/issues/416).
This is a hard design philosophical change and is not easy to deal with. Time will tell.
3. As an extension to #2, the way that thinking in SIMD is hard in the very first place, and to use it in production you even have to think about different situations. This come in the form of dynamic dispatch, and it is a pain to dealt with, although we have great helpers such as multiversion...it is still very hard to design an interface that scales. Take Google's highway (https://github.com/google/highway/blob/master/g3doc/quick_re...) for example, it is the library to write portable SIMD code with dynamic dispatch in C++, but in an esotheric and not so ergonomic way. How we could do better with std::simd is still a myth. How do you abstract the idea of scatter-gather operation? What the heck is swizzle? Why do we call it shuffle and not permutation. Lots of stuff to learn, that means lots of pain to go through.
4. Plus, when you think in SIMD, there could be multiple instructions and multiple ways to do the same thing, one maybe more efficient than the other.
For example, as I have to touch some finite field stuff in GF(2^8), there are few ways to do finite field multiplication:
a. Precomputed table lookup
b. Russian Peasant Multiplication (basically carryless Karatsuba multiplication, but oftenly reduce to the form of table lookups as well, can also seen as ripple counter with modulo arithmetic except carry has to be delivered in a different way)
c. Do an inner product and then do Barrett reduction (https://www.esat.kuleuven.be/cosic/publications/article-1115...)
d. Or just treat it as multiplcation over a polynominal power series but this essentially mean we treat it as a finite field convolution, which I suspect is highly related to fourier transform. (https://arxiv.org/pdf/1102.4772)
e. Use the somewhat new GF2P8AFFINEQB (https://www.felixcloutier.com/x86/gf2p8affineqb) from GFNI which, contrary to most people who think it is available for AVX512 only, but is actually available for SSE/AVX/AVX2 as well (this is called GFNI-SSE in gcc), so it works on my 13600KF too (except obviously I cannot use ZMM registers or I just get illegal instruction for any instructions that touches ZMM or uses the EVEX encoding).
I have an internal implementation of finite field multiplication using just that, but I need to use the polynomial of 0x11D rather than 0x11B so GF2P8MULB (https://www.felixcloutier.com/x86/gf2p8mulb) is out of question (which is supposed to be the fastest in the world theoretically if we can use arbitary polynomial), but this is rather hard to understand and explain in the first place. (by the way I used SIMDE for that: https://github.com/simd-everywhere/simde)
All of these can be done in SIMD, but each one of these methods have its pros and cons. Table lookup maybe fast and seemingly O(1) but you actually need to keep the table in cache, meaning we trade time with space, and SIMD would amplify the cache thrashing from multiple access. This could slow down the CPU pipeline although modern CPU are clever enough on cache management. If you want to do Russian Peasant Multiplication then you need a bunch of loops to go through the division and XOR chunk by chunk.
If you want Barrett reduction then you need to have efficient carryless multiplication such as PCLMULQDQ (https://www.felixcloutier.com/x86/pclmulqdq), to do the inner product and reduce the polynomial. Or a more primitive way find ways to do finite field Horner's method in SIMD...
How to think in SIMD is already hard as said in #3. How to balance in SIMD like this is even harder.
Unless you want to have a certain edge, or want to shatter the benchmark, I would say SIMD is not a good investment. You need to use SIMD at the right scenario at the right time. SIMD is useful, but also kind of niche, and modern CPU is optimized well enough that the performance of general solutions without using SIMD, is good enough too, since all of which will eventually dump right down to the uops anyway, with deep pipeline, branch predictor, superscalar and speculative execution doing their magics altogether, and most of the time if you want to use SIMD, using the easiest SIMD methods is generally enough.
*: I myself used std::simd intensively in my own project, well it got refused that the paper was actually severely lacking in literature studies, but that I shouldn't have used LLM too much to generate the paper.
However, the code was here (https://github.com/stevefan1999-personal/sigmah). Now I have a new approach to this problem that is derived from my current work with finite field, error correction, divide and conquer and polynominal multiplication, and I plan to resubmit the paper once I have time to clear it, with a more careful approach next time too, although the problem of string matching with don't care can be seen as convolution and I doubt my approach would ended up something like that...making the paper still unworthy for acceptance.
In C++, this can be achieved portably using the Highway library: https://github.com/google/highway
(Disclaimer: I work at Google, but not on this, and I am writing this in my personal capacity.)
In Vectorizing for Fun and PerformanceCPU-time would over-emphasize regions where many threads are running, right?
I find wall-time useful for finding serial regions that aren't yet parallelized.
More detail here: https://github.com/dvyukov/perf-load. We recently implemented the same idea without requiring context-switch events: https://github.com/google/highway/blob/master/hwy/profiler.h...
In Java 25's new CPU-Time ProfilerShowing the 15 most recent of 107 sources. Enable JavaScript to search and browse every indexed mention.