That is not a solution for Miles or his package users anyways, since then the users would be implicitly version locked to 1.10? I know from my self, that I have not in the past not upgraded Julia to stick to one package, the only time I remember actually considering not to upgrade, is in this case for the upcoming 1.11, since my work at the time would be meaningless without LoopVectorization.jl - it would become too slow to be practical.
I think there are a lot of valid points floating around, such as to get somewhere better one has to forego the best solution currently, but it is a bit scary for the eco-system as a whole when one package is deprecated and performance tanks in multiple different packages from all kind of projects.
I think the stress would be a lot lower, if someone could show-case how to get near similar level of performance as LoopVectorization without using it - but I have not seen anyone do that yet.
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.
^ 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!
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?
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.
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.
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.
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?
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…
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
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.
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:
Estimated Cost to Develop (organic) $2,599,402
Estimated Schedule Effort (organic) 19.77 months
Estimated People Required (organic) 11.68
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.