What does this mean for packages like Tullio.jl?
2 Likes
Tullio.jl only weakly depends on LoopVectorization.jl. The @avx macro might not work as effectively with Julia 1.11 if it is not updated. Ping @mcabbott .
2 Likes
Tullio should continue to work, but obviously without the benefit from LoopVectorization. It will still (in many cases) apply blocking & multi-threading.
7 Likes
Maintaining LoopVectorization is far beyond my capabilities, but I am willing to pay a bounty to help incentivize volunteers in maintaining it until LoopModels is ready. If someone can point me to a reliable open-source bounty site, I will put up US $100 right now to support the effort.
13 Likes
I believe thereās no such thing on the market currently, Bountysource is defunct/scammy for some time now already: Bountysource - Wikipedia
If you wanted to contribute funds, you can use Julia Language - Open Collective
We can then see to it that whoever completes the task can invoice the amount.
5 Likes
Would it be possible to create a āProjectā there for LoopVectorization, so hopefully others will also contribute?
2 Likes
Done. Iāll rely on you to route the contribution to the correct person(s) after Julia 1.11 compatibility is achieved.
17 Likes
Just matched and put in $100 as well, also for LoopVectorization.jl efforts. Too much of an important project to just let it get deprecated!
22 Likes
Mason was so kind as to elaborate in DM:
"Itās not about performance, itās more about maintanability and reliable abstractions.
A lot of the things one does in julia for performance are not really guarantees, but just doing things and hoping the compiler cooperates. Thatās fine for applications, but can be quite rough for maintaining a library that many other people depend on."
6 Likes
Does dropping LoopVectorization have any impact on the performance of Tullio?
Just now I was saying how easy parallelism is with LoopVectorization and how confusing it seems with JAX. Next thing I know, LoopVectorization is deprecatedā¦ This is sad and looks like a considerable hit for Julia.
2 Likes
If LoopModels is successful in replacing LoopVectorization, then parallelism in Julia should get even better. The question is if LoopModels will be ready by the time that LoopVectorization needs an update.
4 Likes
Apart from the bus factor problem, there seems to be an issue about getting stable APIs for something like LV in Julia. With Julia supposedly having such a focus on high performance computing, thatās somewhat confusing to me. From https://github.com/JuliaSIMD/LoopVectorization.jl/pull/519#issuecomment-1890703114
In terms of maintenance burden, my suggestions would be to avoid anything that isnāt standard, boring Julia code. Of course, that tends to be at odds with getting good performance. So your best bet would probably be to have a close, open dialogue with the core compiler team on getting standard and stable ways of doing everything you need that they approve of.
It would be great if someone more involved with this issue could shed some light on this.
8 Likes
I would like to contribute and put some money. Helping with LoopVectorization.jl maintenance is well beyond my capabilities, but I am happy to help with fundings, however the projects on the linked page do not mention LV.jl. Is this correct or am I wrong? (Tagging @mkitti as he posted the original link)
Also, asking about a couple of other related projects.
Regarding Tullio.jl, my understanding is that if I do not load LV.jl before it, I lose most of the performance. If LV.jl gets deprecated, then which are the alternatives that can still give this kind of speedup now?
Also: SimpleChains.jl. Is it going to be deprecated as well or not? I am heavily using SimpleChains.jl as well, and I am getting worried also about this, since LV.jl is one of SC.jl dependencies (tagging @ChrisRackauckas as well).
I am very sorry for LV.jl to get deprecated. I think @Elrod did a great job with this package and was very valuable for my work. I hope LoopModels will get out by 1.11 (or letās say after not too much after the release).
1 Like
This advice should not be overlooked. Once one starts to write code which depends on the compiler internals, one is subject to undesirable but justifiable churn. The maintenance burden may be bearable at first, but after a couple years, one really has to ask: why canāt I stop re-writing the same code? (answer: I depend on compiler internals).
Deprecation of LoopVectorization.jl is for the best when considered in the larger scope of the Julia language. For the past few years, it has been a very successful proof of concept, but one must acknowledge that it is a local optimum, and, in order to progress toward the global optimum, it is sometimes necessary to take steps which decrease oneās objective function. I believe that most readers are familiar with this from mathematical optimization; and, somewhat surprisingly, human progress is not so dissimilar.
Cheers @Elrod
16 Likes
In view of the tremendous success and adoption of LoopVectorization, I feel that the considerable maintenance burden could well be worth it, from a high-level ecosystem point of view.
Alas, we cannot intrude on @Elrod 's personal time with high-level ecosystem arguments, and it seems unlikely that anybody else will step up or pay up (Iād naively guess maybe $30k for a 3-month contract to port to 1.11? Not pocket / crowd-funding money, either industry or grant).
Well-known curse of OSS funding (obligatory xkcd).
So we had a good time while it lasted, and big thanks to @Elrod for that! 
15 Likes
My question still remains unanswered though: why does Julia not provide public APIs for vectorization such that a project like LV does not have to be a performance maintenance nightmare? I mean it is vectorization, not some random thing. Could as well become part of the language at some point. Iām asking out of ignorance about the hows and whys of LV breakage.
2 Likes