# Why is LoopVectorization deprecated?

**URL:** <https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547>\
**Category:** Performance\
**Tags:** loopvectorization\
**Created:** [February 1, 2024, 2:13am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547 "2024-02-01T02:13:46Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![wujinq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wujinq/32/22221_2.png) [@wujinq](https://discourse.julialang.org/u/wujinq)\
**Post date:** [February 1, 2024, 2:13am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/1 "2024-02-01T02:13:46Z")

</div>

In the README file of [JuliaSIMD/LoopVectorization.jl: Macro(s) for vectorizing loops. (github.com)](https://github.com/JuliaSIMD/LoopVectorization.jl) it is clearly stated that the package is deprecated for Julia 1.11 and newer versions, without any explanation. Anyone knows what’s going on here?

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [February 1, 2024, 2:44am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/2 "2024-02-01T02:44:33Z")

</div>

See the discussion in [Deprecate LV for Julia \>= 1.11-DEV by chriselrod · Pull Request #519 · JuliaSIMD/LoopVectorization.jl · GitHub](https://github.com/JuliaSIMD/LoopVectorization.jl/pull/519) … it looks like most of the developers’ efforts are now focused on the successor project [GitHub - LoopModels/LoopModels: "Full speed or nothing." - James Hetfield](https://github.com/LoopModels/LoopModels)

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [February 1, 2024, 2:58am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/3 "2024-02-01T02:58:20Z")

</div>

But the last human commit to LoopModels is 7 months ago… Looks like a somewhat dangerous situation to me…

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [February 1, 2024, 3:12am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/4 "2024-02-01T03:12:25Z")

</div>

LoopModels/Math has more recent commits.

I’d be interested in a laymen-accessible explanation of the move from LoopVectorization to LoopModels in an easily discoverable place (so not something that can get buried in discourse). What I gather so far is the optimized code generation is going from Julia metaprogramming to LLVM. I don’t know what advantages that brings, but it seems natural to essentially expand the compiler in LLVM.

---

<div class="post-metadata">

**Author:** ![wujinq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wujinq/32/22221_2.png) [@wujinq](https://discourse.julialang.org/u/wujinq)\
**Post date:** [February 1, 2024, 3:45am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/5 "2024-02-01T03:45:40Z")

</div>

LoopModels seems to be more a C++ project than a Julia project, and currently we don’t even have a Julia interface to it. The project is still under rapid development (the main branch is not active but most commits are in the opt branch).

---

<div class="post-metadata">

**Author:** ![frankier](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/frankier/32/35101_2.png) [@frankier](https://discourse.julialang.org/u/frankier)\
**Post date:** [February 1, 2024, 4:47am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/6 "2024-02-01T04:47:17Z")

</div>

Reading between the lines not so much, there seems to have been a mild disagreement between the core compiler developers and Chris Elrod. I guess people don’t like when you mess with their internal interfaces. The whole setup inevitably causes code churn and therefore frustration. Now it’s code churn for the users. I wish there had been some kind of pragmatic path forward. At any rate, implementing at the LLVM level will be more stable long term, but it sure would be nice to have a stopgap. However, I guess it is up to us end users to try and figure out some kind of alternative `@gofast`, and there’s a bit of time to do so, so we can take it in our stride.

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [February 1, 2024, 9:48am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/7 "2024-02-01T09:48:45Z")

</div>

See the Zulip thread here:

[https://julialang.zulipchat.com/#narrow/stream/137791-general/topic/End.20of.20the.20road.20for.20LoopVectorization.2Ejl.20.3F/near/412392536](https://julialang.zulipchat.com/#narrow/stream/137791-general/topic/End.20of.20the.20road.20for.20LoopVectorization.2Ejl.20.3F/near/412392536)

---

<div class="post-metadata">

**Author:** ![gtgt](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gtgt/32/46932_2.png) [@gtgt](https://discourse.julialang.org/u/gtgt)\
**Post date:** [February 1, 2024, 10:09am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/8 "2024-02-01T10:09:12Z")

</div>

No commits have been pushed to the `master` branch for the last 5 months but development is still going on in other branches. You can look at the `opt` branch in the LoopModels repository.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [February 1, 2024, 2:01pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/9 "2024-02-01T14:01:15Z")

</div>

Why are LoopModels being written entirely in C++? Julia not good enough?

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [February 1, 2024, 2:30pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/10 "2024-02-01T14:30:15Z")

</div>

The reason for it being written in C++ is that vectorization is a compiler pass that you want to do after pretty much all of the other optimizations, which pretty much requires it to be an LLVM pass (if you want to avoid some of the issues LoopVectorization had wrt compile time).

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [February 1, 2024, 10:58pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/12 "2024-02-01T22:58:58Z")

</div>

@elrod, is that true? I recall some specific issues with Julia, stack allocation, alloca missing, but that is very specific, and not good to use generally.

> **[alloca() function its advantages and disadvantages - GeeksforGeeks](https://www.geeksforgeeks.org/alloca-function-with-advantages-and-disadvantages/)**
>
> A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.

> **[\_malloca](https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/malloca?view=msvc-170)**
>
> Learn more about: \_malloca

I don’t think C++ (or C) is better generally, for speed (at least single-threaded), and can’t think of any other advantage (plus GC as a difference). I think it has to do with as Oscar mentioned, needing to be an LLVM pass.

Even C++ standard library doesn’t have it, but he favors a hybrid stack/heap allocation only in LLVM, built on alloca, because you do not want to arbitrarily large on the stack.

---

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [February 1, 2024, 11:05pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/13 "2024-02-01T23:05:37Z")

</div>

> can’t think of any other advantage

less likely to have random huge regressions, for one. c++ performance is definitely more _predictable_, even if peak performance potential is comparable

---

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [February 1, 2024, 11:24pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/14 "2024-02-01T23:24:47Z")

</div>

> [@PetrKryslUCSD](#):
>
> Why are LoopModels being written entirely in C++? Julia not good enough?

Its not a question of C++ vs julia but rather at what compiler stage you want to run the thing.

Afaiu LoopVectorization.jl runs on expressions. Code operating on julia expressions is most conveniently written in julia (the lisp heritage shows).

LoopModels will instead operate on LLVM IR, i.e. a much later compiler stage. Code operating on LLVM datastructures is most conveniently written in C++, basically because llvm C-bindings and anything/C++ interop suck, and llvm itself is a C++ project.

From a technical viewpoint, I’d naively think that julia SSAIR looks much more suited (an intermediate representation between expression and llvm). I would guess that here stability / API-politics play a big role: Julia core/compiler does not want to offer stability guarantees on SSAIR, in order to not restrict future progress; so projects using that need to either get upstreamed into julia core, or need to fight an unending battle to stay compatible. (same issue as e.g. linux kernel)

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [February 1, 2024, 11:36pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/15 "2024-02-01T23:36:01Z")

</div>

> [@adienes](#):
>
> [C++] less likely to have random huge regressions

What do you mean? Recompilation? I think Julia can do without those inherently, just not practically yet.

---

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [February 1, 2024, 11:42pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/16 "2024-02-01T23:42:34Z")

</div>

no, I mean performance regressions in the same code

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [February 2, 2024, 12:23am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/17 "2024-02-02T00:23:43Z")

</div>

> [@Oscar\_Smith](#):
>
> vectorization is a compiler pass that you want to do after pretty much all of the other optimizations, which pretty much requires it to be an LLVM pass

> [@foobar\_lv2](#):
>
> LoopModels will instead operate on LLVM IR, i.e. a much later compiler stage.

So why did LoopVectorizations work on Julia expressions and how did it work as well as it did? LoopModels working on LLVM IR sounds more straightforward and, if I’m understanding the purpose of LLVM correctly, sounds like it could be applied to more languages than Julia.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [February 2, 2024, 12:39am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/18 "2024-02-02T00:39:23Z")

</div>

> [@Benny](#):
>
> if I’m understanding the purpose of LLVM correctly, sounds like it could be applied to more languages than Julia.

Yes, LoopModels will be able to support languages other than Julia AFAIK.

> [@foobar\_lv2](#):
>
> I would guess that here stability / API-politics play a big role: Julia core/compiler does not want to offer stability guarantees on SSAIR, in order to not restrict future progress; so projects using that need to either get upstreamed into julia core, or need to fight an unending battle to stay compatible. (same issue as e.g. linux kernel)

But I think the same would hold for LoopModels, too, except with Julia replaced by LLVM, given that the LLVM IR isn’t stable across LLVM releases?

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [February 2, 2024, 1:12am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/19 "2024-02-02T01:12:55Z")

</div>

It worked as well as it did because it got some of the important parts very correct (cost modeling codegen), but had some fairly significant limitations based on being so early in the pipeline. For example, it isn’t able to deal with complex numbers or other user defined structs. It also has a significant impact on compile time since it tends to blow up the size of your code.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [February 2, 2024, 1:22am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/20 "2024-02-02T01:22:58Z")

</div>

For me LoopVectorization.jl is really more about demonstrating what is possible rather than the long term approach to the issue of autovectorization in Julia. Autovectorization probably belongs deeper in the Julia compiler or perhaps as a compiler plugin.

The more interesting part of Julia SIMD for me is the explicit SIMD. Explicit in that the programmer is targeting specific LLVM intrinsics. This is exemplified by SIMD.jl and VectorizationBase.jl.

I also want to point out progress on SIMD that the Java ecosystem is making via Project Panama’s Vector API. This may be a source of inspiration for the future.  
[https://openjdk.org/jeps/438](https://openjdk.org/jeps/438)

---

<div class="post-metadata">

**Author:** ![tbeason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tbeason/32/15898_2.png) [@tbeason](https://discourse.julialang.org/u/tbeason)\
**Post date:** [February 2, 2024, 3:23am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/21 "2024-02-02T03:23:18Z")

</div>

What does this mean for packages like Tullio.jl?

[Next page](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547.md?page=2)