HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
JuliaSIMD
LoopVectorization.jl
Julia2020–2023
JuliaSIMD / LoopVectorization.jl

LoopVectorization.jl

Macro(s) for vectorizing loops.

10Distinct people
17Mentions
0Explicit recommenders
795GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Macro(s) for vectorizing loops.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these 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, 12:54:37 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 year17 dated mentions

Observed mentions: 2020-02-02 17:47:58 UTC to 2023-05-02 17:18:16 UTC.

02468102020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC918
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC303
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC404
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101

What Hacker News says

17 sources
It is a little disappointing that they're setting the bar against vanilla Python in their comparisons. While I'm sure they have put massive engineering effort into their ML compiler, the demos they showed of matmul are not that impressive in an absolute sense; with the analogous Julia code, making use of [LoopVectorization.jl](https://github.com/JuliaSIMD/LoopVectorization.jl) to automatically choose good defaults for vectorization, etc... julia> using LoopVectorization, BenchmarkTools, Test function AmulB!(C,A,B) @turbo for n = indices((C,B),2), m = indices((C,A),1) Cmn = zero(eltype(C)) for k = indices((A,B),(2,1)) Cmn += A[m,k]*B[k,n] end C[m,n]=Cmn end end M = K = N = 14
Read the rest
4; A = rand(Float32, M,K); B = rand(Float32, K,N); C0 = A*B; C1 = similar(C0); AmulB!(C1,A,B) @test C1 ≈ C0 2e-9*M*K\*N/@belapsed(AmulB!($C1,$A,$B)) 96.12825754527164 I'm able to achieve 96GFLOPs on a single core (Apple M1) or 103 GFLOPs on a single core (AMD EPYC 7502). And that's not even as good as what you can achieve using e.g. TVM to do the scheduling exploration that Mojo purports to do. Perhaps they have more extensive examples coming that showcase the capabilities further. I understand it's difficult to show all strengths of the entire system in a short demonstration video. :) EDIT: As expected, there are significantly better benchmarks shown at https://www.modular.com/blog/the-worlds-fastest-unified-matr... so perhaps this whole discussion truly is just a matter of the demo not showcasing the true power of the system. Hopefully achieving those high performance numbers for sgemm is doable without too much ugly code.
In Mojo – a new programming language for AI developers
I do think that Genoa's approach is a reasonable one. I'd like to see one of Gracemont's successors doing the same. Maybe we'll even see quadruple pumping for AVX-512 some day? I'll be impressed if/when an Atom line CPU gets 4x 128bit fma units to match ARM's Cortex-X line or Apple's Firestorm). I think these are good options, and can allow AVX-512 to sort of act like SVE, but with the benefits of a fixed size architecture (i.e., shuffles); compile one set of code and you're able to run it anywhere, with performance dictated by how much the vendor decided was worth investing into the vector units. And AVX512 can still help (like it does Genoa) by taking a lot of pressure off of the front end. I'm also trying to do my part as a software dev! I wrote/maintain the JuliaSIMD ecosystem, and working on good loop vectorizers to let people take a
Read the rest
dvantage of their vector units is my passion; LoopVectorization.jl has gotten great results on many benchmarks[0], and I'm rewriting it as an LLVM pass to try and address as many of its flaws and limitations as I can. [0] For example, in a simple self-dot-product benchmark, LLVM's 256 bit code is actually faster than its 512 bit code when testing random sizes from 1-256: https://github.com/JuliaSIMD/LoopVectorization.jl/issues/446... However, LoopVectorization.jl's 512 bit code is close to twice as fast as either LLVM's 256 bit or 512 bit code. This is a trivial example; the difference can be much larger for more complicated code.
In Knight’s Landing: Atom with AVX-512
> My mistake in retrospect was using small arrays as part of a struct, which being immutable got replaced at each time step with a new struct requiring new arrays to be allocated and initialized. I would not have done that in c++, but julia puts my brain in matlab mode. I see. Yes, it's an interesting design space where Julia makes both heap and stack allocations easy enough, so sometimes you just reach for the heap like in MATLAB mode. Hopefully Prem and Shuhei's work lands soon enough to stack allocate small non-escaping arrays so that user's done need to think about this. > Alignment I'd assumed, but padding the struct instead of the tuple did nothing, so probably extra work to clear a piece of an simd load. Any insight on why avx availability didn't help would be appreciated. I did verify some avx instructions were in the asm it gener
Read the rest
ated, so it knew, it just didn't use. The major differences at this point seem to come down to GCC (g++) vs LLVM and proofs of aliasing. LLVM's auto-vectorizer isn't that great, and it seems to be able to prove 2 arrays are not aliasing less reliably. For the first part, some people have just improved the loop analysis code from the Julia side (https://github.com/JuliaSIMD/LoopVectorization.jl), forcing SIMD onto LLVM can help it make the right choices. But for the second part you do need to do `@simd ivdep for ...` (or use LoopVectorization.jl) to match some C++ examples. This is hopefully one of the things that the JET.jl and other new analysis passes can help with, along with the new effects system (see https://github.com/JuliaLang/julia/pull/43852, this is a pretty huge new compiler feature in v1.8, but right now it's manually specified and will take time before things like https://github.com/JuliaLang/julia/pull/44822 land and start to make it more pervasive). When that's all together, LLVM will have more ammo for proving things more effectively (pun intended).
In Python 3.11 vs 3.10 performance
And the "how" behind Octavian.jl is basically LoopVectorization.jl [1], which helps make optimal use of your CPU's SIMD instructions. Currently there can some nontrivial compilation latency with this approach, but since LV ultimately emits custom LLVM it's actually perfectly compatible with StaticCompiler.jl [2] following Mason's rewrite, so stay tuned on that front. [1] https://github.com/JuliaSIMD/LoopVectorization.jl [2] https://github.com/tshort/StaticCompiler.jl
In Why We Use Julia, 10 Years Later
I agree with you that Fortran is running on more than just legacy here. At the same time, I also think Julia has caught up a lot as far as SIMD, multicore, MPI and GPU. For SIMD, Chris Elrod's LoopVectorization.jl [1] is an (IMHO) incredibly impressive piece of work (which incidentally provides the foundation for I think the first pure Julia linear algebra library competitive with BLAS). Multithreading is pretty easy with things like `@spawn`/`@sync` and `@threads for` in the base language, as well as super low-overhead multithreading from the Polyester.jl [2] package (which LoopVectorization also uses to provide a version its vectorization macro that'll also multithread your loops in addition to SIMD-vectorizing them). MPI.jl [3] has been totally problem free for me, though I wouldn't be surprised if the Fortran bindings still have an ed
Read the rest
ge somewhere, and Cuda.jl [4] seems to provide pretty seamless GPU support which should play nicely with MPI.jl's Cuda-aware MPI [5], but I don't work as much with GPUs myself. [1] https://github.com/JuliaSIMD/LoopVectorization.jl [2] https://github.com/JuliaSIMD/Polyester.jl [3] https://github.com/JuliaParallel/MPI.jl [4] https://github.com/JuliaGPU/CUDA.jl [5] https://juliaparallel.github.io/MPI.jl/latest/usage/#CUDA-aw...
In Fortran is easy to learn
Yes, and sorry if I also came off as combative here, it was not my intention either. I've used some Common Lisp before I got into Julia (though I never got super proficient with it) and I think it's an excellent language and it's too bad it doesn't get more attention. I just wanted to share what I think is cool about julia from a metaprogramming point of view, which I think is actually its greatest strength. > here is a hypothetical question that can be asked: would a julia programmer be more powerful if llvm was written in julia? i think the answer is clear that they would be Sure, I'd agree it'd be great if LLVM was written in julia. However, I also don't think it's a very high priority because there are all sorts of ways to basically slap LLVM's hands out of the way and say "no, I'll just do this part myself." E.g. consider LoopVectori
Read the rest
zation.jl [1] which is doing some very advanced program transformations that would normally be done at the LLVM (or lower) level. This package is written in pure Julia and is all about bypassing LLVM's pipelines and creating hyper efficient microkernels that are competitive with the handwritten assembly in BLAS systems. To your point, yes Chris' life likely would have been easier here if LLVM was written in julia, but also he managed to create this with a lot less man-power in a lot less time than anything like it that I know of, and it's screaming fast so I don't think it was such a huge impediment for him that LLVM wasn't implemented in julia. [1] https://github.com/JuliaSIMD/LoopVectorization.jl
In Why Lisp? (2015)
Growing up, what my late father probably wanted most from me is for me to find a project of my own. When I was in high school, he once threatened me with "get a life, or I will get you one". Engines, and especially motorcycles, were always a passion of his. He grew up on a farm, and "was rebuilding tractor engines when the other kids were learning to ride bicycles." He still holds a few land speed records he set with motorcycles he designed and built. But I had no real hobbies or passions of my own, other than playing card games. It wasn't until my twenties, after I already graduated college with degrees I wasn't interested in and my dad's health failed, that I first tried programming. A decade earlier, my dad was attending the local Linux meetings when away from his machine shop. Programming, and especially performance optimization/loop
Read the rest
vectorization are now my passion and consume most of my free time (https://github.com/JuliaSIMD/LoopVectorization.jl). Hearing all the stories about people starting and getting hooked when they were 11 makes me feel like I lost a dozen years of my life. I had every opportunity, but just didn't take them. If I had children, I would worry for them.
In A Project of One’s Own
I think it's more interesting to see what people do with the language instead of focusing on microbenchmarks. There's for instance this great package https://github.com/JuliaSIMD/LoopVectorization.jl which exports a simple macro `@avx` which you can stick to loops to vectorize them in ways better than the compiler (=LLVM). It's quite remarkable you can implement this in the language as a package as opposed to having LLVM improve or the julia compiler team figure this out. See the docs which kinda read like blog posts: https://juliasimd.github.io/LoopVectorization.jl/stable/ And then replacing the matmul.jl with the following: @avx for i = 1:m, j = 1:p z = 0.0 for k = 1:n z += a[i, k] * b[k, j] end out[i, j] = z end I get a 4x speedup from 2.72s to 0.63s. And with @avxt (threaded) using
Read the rest
8 threads it goes town to 0.082s on my amd ryzen cpu. (So this is not dispatching to MKL/OpenBLAS/etc). Doing the same in native Python takes 403.781s on this system -- haven't tried the others.
In Julia 1.6 Highlights
Julia's SIMD programming model is still very much a work in progress; I think we have a way to go in providing the kind of flexibility and control that languages such as ISPC, Halide, TVM, etc... provide. That being said, packages such as SIMD.jl [0], and LoopVectorization.jl [1] are making fantastic progress, to the point that LoopVectorization forms the basis of a legitimate BLAS contender, in pure Julia [2]. It's not totally there yet, but it's close enough that real work is being done in LV at OpenBLAS-like speeds. As an aside, I find it incredible that these kinds of extensions can be built in packages thanks to the fact that Julia's compiler is extensible enough to allow for direct manipulation of the LLVM intrinsics being emitted by user code. [0] https://github.com/eschnett/SIMD.jl [1] https://github.com/chriselrod/LoopVectorizat
Read the rest
In The Accelerating Adoption of Julia
I should include more detailed instructions. Dependencies include: eigen, gcc, clang, and (harder) the Intel compilers, as well as a recent version of Julia. If you have those, you should be able to instantiate the Manifest: https://github.com/chriselrod/LoopVectorization.jl/tree/mast... and then `include("/path/to/LoopVectorization/benchmark/driver.jl")` to run the benchmarks. There are other examples. For example, for code as simple as the dot products, clang shows some pretty bad performance characteristics while gcc needed a few infrequently used compiler options to do well there. Image filtering / convolutions without compile-time known kernel sizes are another example that showed dramatic speedup. When talking about optimized gemm, LoopVectorization currently only does register tiling. Therefore its matmul performance will continue
Read the rest
to degrade beyond 200x200 or so on my deskop. An optimized BLAS implementation would still need to take care of packing arrays to fit into cache, multithreading, etc. Maybe I should add pluto. I did test Polly before, but it took several minutes to compile the simple c file, and the only benchmark that seemed to improve was the gemm without any transposes. And it still didn't perform particularly well there -- worse than the Intel compilers, IIRC. PRs are welcome.
In Can we do better than our C compiler?
There is a recent effort [1] to provide low-level support for faster operations by transforming user code to take advantage of a compiler's instruction set, memory packing, etc. This is being expanded upon to essentially provide a Julia-native BLAS. Some of the benchmarks are even competitive with or beat Intel MKL (calibrate that statement appropriately to your level of trust in benchmarks). I wouldn't count out a Julia ARPACK implementation just yet. [1] LoopVectorization: https://github.com/chriselrod/LoopVectorization.jl Announcement post and discussion: https://discourse.julialang.org/t/ann-loopvectorization/3284...
In Grassmann.jl A\b 3x faster than Julia's StaticArrays.jl
This was a nice writeup! I know there was an explicit mention that non-standard library packages were omitted due to fiddlyness in installation, but with Julia using the manifest system, providing reproducible setups should be easy, and for things like this, Chris Elrod's LoopVectorization.jl [1] should offer substantial speedups with some simple macro annotations. [1] https://github.com/chriselrod/LoopVectorization.jl
In A Look at Chapel, D, and Julia Using Kernel Matrix Calculations
> It's not JUST google and apple, I'm sure they have enough cash and expertise and will to create enough momentum to attract more domain experts in other areas. Maybe, but I'm doubtful. Scientific domain experts flock to languages like Python, Julia, Matlab, R, etc. because they're interactive and allow them to quickly iterate on ideas, query data, produce plots, etc. Swift is not much of an interactive language and is not built around that kind of repl driven experience. > In particular, do you have another example aside from DifferentialEquations.jl ? Sure, here's a smattering of high quality packages made by and for research scientists: https://github.com/JuliaApproximation/ApproxFun.jl https://github.com/BioJulia https://github.com/JuliaDiffEq/ModelingToolkit.jl https://github.com/crstnbr/MonteCarlo.jl https://gith
Read the rest
In Julia 1.4

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.