Thread

Platform-independent SIMD in Go

414 points · 152 comments · yurivish

qprofyeh · 1790338880 · focus · HN ↗
This feature opens many doors for optimizing low-level performance in Go projects, that are already running multicore. IIRC there aren’t a lot of languages with built-in std lib support for SIMD and variants. Love the way Go is trying new stuff lately.
1. abirch · 1790340337 · focus · HN ↗
  Vectorizing computations has been Matlabs secret sauce.
  1. mastermage · 1790340684 · focus · HN ↗
    Julia does that too.
  2. KeplerBoy · 1790341362 · focus · HN ↗
    Does matlab these days do stuff like JIT operator fusing to avoid memory roundtrips and take advantage of FMAs?
    abirch · 1790343670 · focus · HN ↗
    Yes: <a href="https://www.mathworks.com/help/fixedpoint/ref/half.fma.html" rel="nofollow">https://www.mathworks.com/help/fixedpoint/ref/half.fma.html
    I'm grateful that Go a non-proprietary language offers these features.
2. pjmlp · 1790341259 · focus · HN ↗
  Besides the usual C and C++, we have Java, .NET, D, Zig, Julia, Swift, Rust.
  So yeah, also appreciate having Go in the group instead of manually having to write Assembly.
  However not many languages adopt ways to manually write SIMD, because most of us have no idea how to write good SIMD code in first place, I surely don't.
  1. stingraycharles · 1790342264 · focus · HN ↗
    Even with languages that adopt ways to manually write SIMD, it’s mostly left to library maintainers rather than application developers.
    I work for a C++ timeseries database startup that leverages SIMD about as much as we possibly can, and except for some extremely rare places we just use libraries.
    pjmlp · 1790343414 · focus · HN ↗
    Yeah, that is what I have heard from some NVidia folks as well, like Bryce Adelstein, use the libraries as much as possible, and leave the kernels for experts.
    However even then, it depends on how the libraries API surface looks like.
  2. Thaxll · 1790342583 · focus · HN ↗
    With AI I'm pretty sure SIMD will be easier to integrate when necessary.
    pjmlp · 1790343236 · focus · HN ↗
    With AI, I expect it to eventually be good enough for us to finally have 5 GLs, so it won't really matter.
    "CGO 2022 Keynote: Compiler 2.0"
    <a href="https://www.youtube.com/watch?v=w_sX9aZoZxg" rel="nofollow">https://www.youtube.com/watch?v=w_sX9aZoZxg
    stingraycharles · 1790343634 · focus · HN ↗
    But it’s not necessary at all, the whole point is that these utility libraries bring you more elegant code that work on all platforms without having to pollute your codebase with SIMD intrinsics.
    Unless this was tongue in cheek, because this is in fact a problem with AI that it degrades your codebase in these types of ways.
    preisschild · 1790348441 · focus · HN ↗
    In 2026 if you are not doing A with AI you are doing it wrong /s
  3. vlod · 1790353136 · focus · HN ↗
    You probably weren't looking for a tutorial about SIMD, but just in case you were interested, Mitchell [0] did one recently that got on HN [1]
    [0] Mitchell Hashimoto: "Everyone Should Know SIMD" <a href="https://mitchellh.com/writing/everyone-should-know-simd" rel="nofollow">https://mitchellh.com/writing/everyone-should-know-simd
    [1] <a href="https://news.ycombinator.com/item?id=49010648">https://news.ycombinator.com/item?id=49010648
    janwas · 1790358311 · focus · HN ↗
    We recently published another: <a href="https://github.com/google/highway/blob/master/g3doc/tutorial.md" rel="nofollow">https://github.com/google/highway/blob/master/g3doc/tutorial...
    setr · 1790362117 · focus · HN ↗
    I definitely was so... thanks!
    pjmlp · 1790363218 · focus · HN ↗
    Thanks, pretty much appreciated, always worth at least to skim through.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.