# 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:** 6
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [April 2, 2024, 12:06am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/102 "2024-04-02T00:06:15Z")
I’m not sure how general this is, but here is one example of “manual” loop vectorization:
> [@Julia & Mojo Mandelbrot Benchmark](https://discourse.julialang.org/t/julia-mojo-mandelbrot-benchmark/103638/16):
>
> This one runs 5x 8x faster then the original julia example posted here, and illustrates nicely how something like ComplexSIMD can be defined quite easily in Julia: const xn = 960 const yn = 960 const xmin = -2.0 const xmax = 0.6 const ymin = -1.5 const ymax = 1.5 const MAX\_ITERS = 200 struct ComplexSIMD{N,T} re::NTuple{N,T} im::NTuple{N,T} end Base.abs2(z::ComplexSIMD) = z.re .\* z.re .+ z.im .\* z.im Base.:(\*)(a::ComplexSIMD, b::ComplexSIMD) = ComplexSIMD( a.re .\* b.re .- a.im .\* b…
Probably, for the time being, people wanting to recover the performance of LV should study how to do something of the sort in their own problems.
---
### Author:  [@Tarny\_GG\_Channie](https://discourse.julialang.org/u/Tarny_GG_Channie)
#### Post date: [April 2, 2024, 9:16am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/103 "2024-04-02T09:16:50Z")
There are some discussions on GPU in this thread. I would say that there are some tasks that require low latency such that the latency of transferring the data to the GPU is not worth the extra compute, but is still branchless, suitable for SIMD. That’s where loopvectorization shines.
---
### Author:  [@TheLateKronos](https://discourse.julialang.org/u/TheLateKronos)
#### Post date: [April 4, 2024, 6:54am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/104 "2024-04-04T06:54:19Z")
> [@MilesCranmer](#):
>
> I guess I just wish LV was somehow integrated into Julia standard library a long time ago so this wouldn’t happen, and any internal changes would be copied over regularly
^ This. I am not sure how feasable it wold actually be, but given how many packages rely on LV for performance gains, and how important performance is to the Julia comunity, it seems like a replacement for LV would be a splendid candidate a new (upgradable) Julia standard library!
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [April 4, 2024, 8:25am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/105 "2024-04-04T08:25:54Z")
> [@TheLateKronos](#):
>
> seems like a replacement for LV would be a splendid candidate a new (upgradable) Julia standard library
On the contrary, I suppose a proper solution would be integrated into the Julia compiler and/or LLVM? Which is exactly what LoopModels is supposed to facilitate, I think?
---
### Author:  [@martin.d.maas](https://discourse.julialang.org/u/martin.d.maas)
#### Post date: [April 10, 2024, 7:23am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/106 "2024-04-10T07:23:09Z")
Too sad to learn about this. LoopVectorization.jl is THE package that blew my mind when I re-discovered Julia about 3 years ago. With LV, I could write super-readable code and get the same performance than manual simd-optimized code, which is crazy-good.
> [@MilesCranmer](#):
>
> I guess I just wish LV was somehow integrated into Julia standard library a long time ago so this wouldn’t happen, and any internal changes would be copied over regularly. Julia promises speed; good vectorization seems key to that promise.
That’s why I’m generally skeptical of bleeding-edge Julia packages that make use of compiler internals nowadays. They are not really getting supported and maintaining them becomes an uphill battle.
---
### Author:  [@martin.d.maas](https://discourse.julialang.org/u/martin.d.maas)
#### Post date: [April 10, 2024, 5:27pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/107 "2024-04-10T17:27:15Z")
As a solution, perhaps we should all learn more about SIMD and create some simple packages, tailored to some specific use cases of SIMD, that are also easier to maintain. In my case, LV was doing the magic for my work involving complex functions… for most other cases I encountered, `@fastmath @inbounds @simd` does the trick of getting nearly-optimal performance.
---
### Author:  [@wujinq](https://discourse.julialang.org/u/wujinq)
#### Post date: [April 22, 2024, 10:55pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/108 "2024-04-22T22:55:45Z")
The README file of LoopVectorization now reads “Looking for new maintainers, otherwise deprecated in Julia 1.11.” How hard is it to find new maintainers? What does it take for an ordinary user to understand LoopVectorization and maintain it?
---
### Author:  [@ctkelley](https://discourse.julialang.org/u/ctkelley)
#### Post date: [May 1, 2024, 4:32pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/109 "2024-05-01T16:32:36Z")
Just tried again with
```julia
Version 1.12.0-DEV.446 (2024-05-01)
LLVM: libLLVM-17.0.6 (ORCJIT, apple-m2)
JULIA_LLVM_ARGS = -enable-vplan-native-path
```
and the results were no better than they were with LLVM 16
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [May 1, 2024, 4:43pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/110 "2024-05-01T16:43:41Z")
> [@wujinq](#):
>
> What does it take for an ordinary user to understand LoopVectorization and maintain it?
Just try to read the [code](https://github.com/JuliaSIMD/LoopVectorization.jl/tree/main/src) and try to understand it. If you understand 30% of it you can become the new maintainer…
```julia
ufechner@framework:~/repos/LoopVectorization.jl$ scc -x toml .
───────────────────────────────────────────────────────────────────────────────
Language Files Lines Blanks Comments Code Complexity
───────────────────────────────────────────────────────────────────────────────
Julia 95 33398 1231 2113 30054 4045
Markdown 22 2195 523 0 1672 0
YAML 7 283 8 10 265 0
C 2 348 11 0 337 83
FORTRAN Modern 2 457 18 14 425 10
C++ 1 116 14 5 97 0
License 1 19 3 0 16 0
SVG 1 12 0 0 12 0
gitignore 1 21 2 0 19 0
───────────────────────────────────────────────────────────────────────────────
Total 132 36849 1810 2142 32897 4138
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $1,058,301
Estimated Schedule Effort (organic) 14.05 months
Estimated People Required (organic) 6.69
───────────────────────────────────────────────────────────────────────────────
Processed 1099814 bytes, 1.100 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────
```
If we assume that you need to invest 20% of the time that was needed to write this code for understanding it and becoming a maintainer, just raise 200,000$ and you can pay someone to pick up this role…
---
### Author:  [@Tarny\_GG\_Channie](https://discourse.julialang.org/u/Tarny_GG_Channie)
#### Post date: [May 2, 2024, 2:12am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/111 "2024-05-02T02:12:37Z")
I don’t know if the estimate would be accurate. This library is far from being typical code.
---
### Author:  [@ericphanson](https://discourse.julialang.org/u/ericphanson)
#### Post date: [May 2, 2024, 10:35am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/112 "2024-05-02T10:35:54Z")
I think SCC tends to overestimate the complexity of julia code, but I think LoopVectorization is a lot more complicated than typical julia code, so it may actually be more accurate there. As a comparison, I checked out v1.0.0 of my ExplicitExports.jl, which I know took about 15-25 hours over 3-4 days, and got
```julia
───────────────────────────────────────────────────────────────────────────────
Language Files Lines Blanks Comments Code Complexity
───────────────────────────────────────────────────────────────────────────────
Julia 15 1895 353 213 1329 218
Markdown 4 220 72 0 148 0
YAML 3 115 0 2 113 0
License 1 21 4 0 17 0
gitignore 1 6 0 0 6 0
───────────────────────────────────────────────────────────────────────────────
Total 24 2257 429 215 1613 218
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $44,628
Estimated Schedule Effort (organic) 4.22 months
Estimated People Required (organic) 0.94
───────────────────────────────────────────────────────────────────────────────
Processed 89070 bytes, 0.089 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────
```
which seems very inflated.
---
### Author:  [@Elrod](https://discourse.julialang.org/u/Elrod)
#### Post date: [May 2, 2024, 11:04am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/113 "2024-05-02T11:04:31Z")
It is inflated. It was only ever a hobby project done in my spare time, certainly not 7 years of my salary.
Many bugs aren’t that hard to fix, and may not require knowing much about the code base at all.
---
### Author:  [@tecosaur](https://discourse.julialang.org/u/tecosaur)
#### Post date: [May 2, 2024, 11:47am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/114 "2024-05-02T11:47:34Z")
This is a tangent, but I’m actually finding SCC (which I’ve first heard of here) rather funny. The cost estimation is a fun idea, but I just tried it in my Emacs config and:
```julia
Estimated Cost to Develop (organic) $2,599,402
Estimated Schedule Effort (organic) 19.77 months
Estimated People Required (organic) 11.68
```
---
### Author:  [@Eben60](https://discourse.julialang.org/u/Eben60)
#### Post date: [May 2, 2024, 1:22pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/115 "2024-05-02T13:22:15Z")
> [@Elrod](#):
>
> It is inflated.
It sets corporate overhead to the factor of 2.4 by default.
---
### Author:  [@tbeason](https://discourse.julialang.org/u/tbeason)
#### Post date: [May 2, 2024, 1:44pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/116 "2024-05-02T13:44:47Z")
Don’t sell yourself short! If someone is willing to front that cost, let them!
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [May 2, 2024, 3:07pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/117 "2024-05-02T15:07:51Z")
Regardless of the exact monetary value, 36k loc in 100+ files is definitely not nothing.
---
### Author:  [@maxfreu](https://discourse.julialang.org/u/maxfreu)
#### Post date: [July 25, 2024, 10:50am UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/118 "2024-07-25T10:50:09Z")
I’ll add another 200$ for making it fit for 1.11. Is there some coordinated way to make such donations to julia projects?
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [July 25, 2024, 1:20pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/119 "2024-07-25T13:20:18Z")
See [SciML Small Grants Program Current Project List](https://sciml.ai/small_grants/)
---
### Author:  [@DNF](https://discourse.julialang.org/u/DNF)
#### Post date: [July 25, 2024, 6:44pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/120 "2024-07-25T18:44:41Z")
Having just watched the “state of Julia” talk from Juliacon, I’m pretty sure it was said during the Q&A that LV has been updated to work on 1.11. But after checking on github, I couldn’t see that it’s been announced.
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [July 25, 2024, 8:45pm UTC](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547/121 "2024-07-25T20:45:49Z")
>
>
> LoopVectorization.jl's generated IR seems to cause segfaults on 1.11, as observe…d on PkgEval with at least 6 packages (MCPhylo,jl, LocalPoly.jl, VectorizedReduction.jl, NaNStatistics.jl, TimeSeriesClassification.jl, PlmDCA.jl). See this report for details: https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by\_hash/2cbecf4\_vs\_18b4f3f/report.html
>
> @chriselrod I'm opening a new issue because https://github.com/JuliaSIMD/LoopVectorization.jl/issues/518 was closed, and to list all issues in case somebody wants to tackle this.
>
> \---
>
> Some of the errors that I've encountered:
>
> An LLVM assertion, as seen with MCPhylo.jl (requires assertions build of Julia):
>
> \`\`\`
> julia: /workspace/srcdir/llvm-project/llvm/lib/IR/Instructions.cpp:2561: void llvm::InsertValueInst::init(llvm::Value\*, llvm::Value\*, llvm::ArrayRef\, const llvm::Twine&): Assertion \`ExtractValueInst::getIndexedType(Agg-\>getType(), Idxs) == Val-\>getType() && "Inserted value must match indexed type!"' failed.
>
> \[177\] signal 6 (-6): Aborted
> in expression starting at /home/pkgeval/.julia/packages/MCPhylo/KWPlY/test/distributions/phylodist.jl:1
> gsignal at /lib/x86\_64-linux-gnu/libc.so.6 (unknown line)
> abort at /lib/x86\_64-linux-gnu/libc.so.6 (unknown line)
> unknown function (ip: 0x7fbeac0f040e)
> \_\_assert\_fail at /lib/x86\_64-linux-gnu/libc.so.6 (unknown line)
> \_ZN4llvm15InsertValueInst4initEPNS\_5ValueES2\_NS\_8ArrayRefIjEERKNS\_5TwineE at /opt/julia/bin/../lib/julia/libLLVM-15jl.so (unknown line)
> InsertValueInst at /source/usr/include/llvm/IR/Instructions.h:2640 \[inlined\]
> Create at /source/usr/include/llvm/IR/Instructions.h:2565 \[inlined\]
> CreateInsertValue at /source/usr/include/llvm/IR/IRBuilder.h:2343
> emit\_new\_struct at /source/src/cgutils.cpp:3870
> emit\_new\_struct at /source/src/julia.h:1704
> emit\_expr at /source/src/codegen.cpp:5945
> emit\_ssaval\_assign at /source/src/codegen.cpp:5367
> emit\_stmtpos at /source/src/codegen.cpp:5642 \[inlined\]
> emit\_function at /source/src/codegen.cpp:8810
> jl\_emit\_code at /source/src/codegen.cpp:9144
> jl\_emit\_codeinst at /source/src/codegen.cpp:9227
> \_jl\_compile\_codeinst at /source/src/jitlayers.cpp:220
> jl\_generate\_fptr\_impl at /source/src/jitlayers.cpp:525
> jl\_compile\_method\_internal at /source/src/gf.c:2509 \[inlined\]
> jl\_compile\_method\_internal at /source/src/gf.c:2397
> \_jl\_invoke at /source/src/gf.c:2912 \[inlined\]
> ijl\_apply\_generic at /source/src/gf.c:3097
> logpdf at /home/pkgeval/.julia/packages/MCPhylo/KWPlY/src/distributions/Phylodist.jl:118
> \`\`\`
>
> A segfault during \`vload\`, as seen with NaNStatistics.jl and PlmDCA.jl:
>
> \`\`\`
> \[60\] signal 11 (2): Segmentation fault
> in expression starting at /home/pkgeval/.julia/packages/NaNStatistics/oBRaH/test/testArrayStats.jl:80
> macro expansion at /home/pkgeval/.julia/packages/VectorizationBase/0dXyA/src/llvm\_intrin/memory\_addr.jl:987 \[inlined\]
> \_\_vload at /home/pkgeval/.julia/packages/VectorizationBase/0dXyA/src/llvm\_intrin/memory\_addr.jl:987 \[inlined\]
> \_vload at /home/pkgeval/.julia/packages/VectorizationBase/0dXyA/src/strided\_pointers/stridedpointers.jl:95 \[inlined\]
> macro expansion at /home/pkgeval/.julia/packages/VectorizationBase/0dXyA/src/vecunroll/memory.jl:60 \[inlined\]
> \_vload\_unroll at /home/pkgeval/.julia/packages/VectorizationBase/0dXyA/src/vecunroll/memory.jl:535 \[inlined\]
> \_vload at /home/pkgeval/.julia/packages/VectorizationBase/0dXyA/src/vecunroll/memory.jl:771 \[inlined\]
> macro expansion at /home/pkgeval/.julia/packages/LoopVectorization/7iB2K/src/reconstruct\_loopset.jl:1107 \[inlined\]
> \_turbo\_! at /home/pkgeval/.julia/packages/LoopVectorization/7iB2K/src/reconstruct\_loopset.jl:1107 \[inlined\]
> \_nanmean at /home/pkgeval/.julia/packages/NaNStatistics/oBRaH/src/ArrayStats/ArrayStats.jl:344
> \_\_nanmean at /home/pkgeval/.julia/packages/NaNStatistics/oBRaH/src/ArrayStats/ArrayStats.jl:308 \[inlined\]
> \#nanmean#5 at /home/pkgeval/.julia/packages/NaNStatistics/oBRaH/src/ArrayStats/ArrayStats.jl:307 \[inlined\]
> nanmean at /home/pkgeval/.julia/packages/NaNStatistics/oBRaH/src/ArrayStats/ArrayStats.jl:307
> \`\`\`
>
> A segfault during \`vadd\_fast\` as seen with VectorizedReductions.jl:
>
> \`\`\`
> \[12\] signal 11 (2): Segmentation fault
> in expression starting at /home/pkgeval/.julia/packages/VectorizedReduction/bsnWJ/test/reduce.jl:4
> macro expansion at /home/pkgeval/.julia/packages/VectorizationBase/xE5Tx/src/llvm\_intrin/binary\_ops.jl:31 \[inlined\]
> vadd\_fast at /home/pkgeval/.julia/packages/VectorizationBase/xE5Tx/src/llvm\_intrin/binary\_ops.jl:31 \[inlined\]
> fmap at /home/pkgeval/.julia/packages/VectorizationBase/xE5Tx/src/vecunroll/fmap.jl:11 \[inlined\]
> fmap at /home/pkgeval/.julia/packages/VectorizationBase/xE5Tx/src/vecunroll/fmap.jl:11 \[inlined\]
> fmap at /home/pkgeval/.julia/packages/VectorizationBase/xE5Tx/src/vecunroll/fmap.jl:11 \[inlined\]
> fmap at /home/pkgeval/.julia/packages/VectorizationBase/xE5Tx/src/vecunroll/fmap.jl:11 \[inlined\]
> fmap at /home/pkgeval/.julia/packages/VectorizationBase/xE5Tx/src/vecunroll/fmap.jl:11 \[inlined\]
> fmap at /home/pkgeval/.julia/packages/VectorizationBase/xE5Tx/src/vecunroll/fmap.jl:11 \[inlined\]
> fmap at /home/pkgeval/.julia/packages/VectorizationBase/xE5Tx/src/vecunroll/fmap.jl:11 \[inlined\]
> vadd\_fast at /home/pkgeval/.julia/packages/VectorizationBase/xE5Tx/src/vecunroll/fmap.jl:111 \[inlined\]
> add\_fast at /home/pkgeval/.julia/packages/VectorizationBase/xE5Tx/src/base\_defs.jl:91 \[inlined\]
> macro expansion at /home/pkgeval/.julia/packages/LoopVectorization/7iB2K/src/reconstruct\_loopset.jl:1107 \[inlined\]
> \_turbo\_! at /home/pkgeval/.julia/packages/LoopVectorization/7iB2K/src/reconstruct\_loopset.jl:1107 \[inlined\]
> macro expansion at /home/pkgeval/.julia/packages/VectorizedReduction/bsnWJ/src/vmapreduce.jl:236 \[inlined\]
> vvmapreduce at /home/pkgeval/.julia/packages/VectorizedReduction/bsnWJ/src/vmapreduce.jl:231
> vvreduce at /home/pkgeval/.julia/packages/VectorizedReduction/bsnWJ/src/vmapreduce.jl:147
> \`\`\`
>
> The source of bad IR hasn't been fully determined yet, but it seems to be the \`Expr(:new)\` that's generated to pass structs by value instead of by reference: https://github.com/JuliaLang/julia/issues/52702#issuecomment-1874492883.
>
> \---
>
> Deprecating LoopVectorization.jl isn't possible, because:
>
> \- some packages, e.g. RecursiveFactorizations.jl, inspect LoopVectorization.jl internals: https://github.com/JuliaSIMD/LoopVectorization.jl/issues/520
> \- the transformation of \`@turbo\` changes semantics, https://github.com/JuliaSIMD/LoopVectorization.jl/pull/523#issuecomment-1884883071
>
> So the only solution forwards seems fixing LoopVectorization.jl. I've taken a first attempt at it in https://github.com/JuliaSIMD/LoopVectorization.jl/pull/523, but just removing the \`Expr(:new)\` optimization isn't sufficient, and there's other issues (see above).
> `check_empty=true/false` didn’t change between early Julia versions and 1.10.
> We could make `check_empty=true` the default.
> Closing this because tests pass on 1.11, while `check_empty=false` should’ve also caused segfaults in older Julia versions. [Test cleanup · JuliaSIMD/LoopVectorization.jl@eeaa0b2 · GitHub](https://github.com/JuliaSIMD/LoopVectorization.jl/actions/runs/8946228352)
But if anyone wants to contribute towards v1.12, the SciML Small Grants outlines that project and we’d be happy to up the ante. Maintenance never ends, so it’ll need v1.13 updates too!
[Previous page](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547.md?page=5)
[Next page](https://discourse.julialang.org/t/why-is-loopvectorization-deprecated/109547.md?page=7)