We also experimented with 4x4 networks but it's very helpful to use 256 or 512-bit SIMD. You might give our vqsort a try, it's quite a bit faster than std::sort: https://github.com/google/highway/blob/master/hwy/contrib/so...
In Sorting with SIMDgoogle
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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:00:59 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
24 sources> Also if I try to isolate the SIMD bits in C++ I’ll lose the opportunity to have them be inlined which will defeat the optimization purpose.
Agreed. Usually the interface would be something like RunEntireAlgorithm(), not DotProduct().
> For those that are new to this, can you give an example of a kind of computation or algorithm which is well-served by your project but not possible with vector extensions
Sure. Vector extensions are OKish for simple math but JPEG XL includes nontrivial cross-lane operations such as
transpose and boundary handling for convolution.
__builtin_shufflevector requires a known vector length, and can be pessimized (fusing two into one general all-to-all permute which is more expensive than two simple shuffles).
Also, vqsort (https://github.com/google/highway/tree/master/hwy/contrib/so...) almost entirely consists
Read the rest
of
operations not supported by the extensions, and actually works out of the box on variable-length RISC-V and SVE, which compiler extensions cannot.
I beg to differ :) std::experimental::simd has a very limited set of operations: mostly just math, very few shuffles/swizzles. Last I checked, it also only worked in a recent version of GCC.
We do indeed have cross-platform intrinsics here: github.com/google/highway. Disclosure: I am the main author.
In Optimizing compilers reload vector constants needlesslyHere's a first draft, comments welcome: https://github.com/google/highway/pull/1078.
In AVX 512 will be the future:) Indeed, we're seeing 10x speedups from SIMD for some distributions.
It's useful both for sorting networks and quicksort partitioning.
Code here: https://github.com/google/highway/tree/master/hwy/contrib/so... (disclosure: I'm one of the co-authors).
In Blitsort: A fast, in-place stable hybrid merge/quick sortHighway: Performance-portable, length-agnostic SIMD with runtime dispatch
2 points · Open discussionCool, I wasn't familiar with libvolk. It seems to be a collection of prewritten kernels, so it only helps if the function you want to write is among them.
github.com/google/highway seems to be closer to what is requested here. It provides around 200 portable intrinsics using which you can write a wide variety of functions (only a single implementation required). Disclosure: I am the main author.
In AVX 512 will be the futureGood news, you can use portable intrinsics (github.com/google/highway) and write your code only once.
(Disclosure: I am the main author.)
In Escaping strings faster with AVX-512:)
For anyone interested, here's a brief discussion of tail handling: https://github.com/google/highway#strip-mining-loops
(Overlapping is indeed cool where it works - idempotent operations.)
In Escaping strings faster with AVX-512:) We (several engineers) put together a table [1] of instructions that several architectures natively support.
There was enough overlap that I thought a wrapper would make sense.
With a lot of the JPEG XL code written, when SVE and RVV were being introduced/discussed, I realized that pretty much the same code would work there, too: we just needed to replace a constexpr VecClass::kLanes with Lanes(), which is what Highway now does.
Beyond the initial set of efficient-everywhere ops, we've added some (such as AbsDiff) that help on say Arm without hurting other platforms, nor can user code do better itself. There are also a few (ReorderWidenMulAccumulate) that define a non-obvious relaxation of the interface which is more efficient for all platforms than holding to any one platform's interface.
For RVV, one remaining concern is the VSETVLI
Read the rest
- the revised intrinsics now require an avl argument, which Highway creates in each function. It's not yet clear whether the compiler will be smart enough to (peephole-?)optimize away the duplicates.
1: https://github.com/google/highway/blob/master/g3doc/instruct...
Indeed a nice speedup!
As to libraries: I'm the main author of github.com/google/highway which provides 'portable intrinsics' so you only have to write your code once for all platforms.
It includes ready to use sorting and searching algorithms in hwy/contrib.
In Filtering a vector with SIMD instructions (AVX-2 and AVX-512)github.com/google/highway is arguably such a collection of tricks, the x86_256-inl.h header does emulate some missing AVX-512 instructions such as this one or compressstoreu.
(In this case we currently use a constant.)
In Unsigned comparisons in AVX2/SSE: a quick noteIt's often possible to avoid fringes via padding/overallocation.
And if not, it may be possible to use unaligned loads/stores to handle the fringe in a single (final) iteration: https://github.com/google/highway#strip-mining-loops
It is actually feasible to write vector-style code using SIMD instructions. Yes, the SIMD ISA is more complicated because of the various accumulated extensions, but this is what we currently have. And a bit larger code size (for one final loop iteration) doesn't seem to be a big deal.
In tolower() in bulk at speedI agree padding is a good solution when you can arrange it.
In Highway we also use the blending/bit-select you mention: https://github.com/google/highway/blob/master/hwy/ops/generi...
If HWY_MEM_OPS_MIGHT_FAULT, which is true if using ASAN or AVX2 (because AMD reserves the right to fault even if mask=0), we actually use a scalar loop.
I'm curious if anyone has data indicating that a jump table is faster, enough to make a difference?
In tolower() in bulk at speedShowing the 15 most recent of 24 sources. Enable JavaScript to search and browse every indexed mention.