LoopVectorization.jl VS py4cl

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...

```

> 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 generated, 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).

This looks nice too. Seems to be maintained and it even has a vmap-function. What more can one ask for ;) https://github.com/JuliaSIMD/LoopVectorization.jl

Have you checked out https://github.com/JuliaSIMD/LoopVectorization.jl ? It may be useful for your specific use case

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

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 LoopVectorization.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

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 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.

Julia will often do SIMD under the hood with either a for loop or a broadcasted version, so you generally shouldn't have to worry about it. But for more advanced cases you can look at https://github.com/JuliaSIMD/LoopVectorization.jl

Very often benchmarks include compilation time of julia, which might be slow. Sometimes they rightfully do so, but often it's really apples and oranges when benchmarking vs C/C++/Rust/Fortran. Julia 1.6 shows compilation time in the `@time f()` macro, but Julia programmers typically use @btime from the BenchmarkTools package to get better timings (e.g. median runtime over n function calls).

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/

py4cl and cl4py rely on uiop:launch-program and python's subprocess respectively. These are portable to the extent uiop and subprocess are portable and do not require any additional installation.

If you want to use Python libs from CL, see py4cl: https://github.com/bendudson/py4cl the other way around, calling your efficient CL library from Python: https://github.com/marcoheisig/cl4py/ There might be more CL libraries than you think! https://github.com/CodyReichert/awesome-cl (or at least a project sufficiently advanced on your field to join forces ;) )

FYI you can call Python from CL: https://github.com/bendudson/py4cl and CL from Python: https://github.com/marcoheisig/cl4py/

If you don't know Emacs, see other editors: https://lispcookbook.github.io/cl-cookbook/editor-support.ht... If you want the more Smalltalk-like experience I'd go with the free LispWorks version: it has many GUI panes that allow to watch and discover the state of the program.

I personally couldn't stay long with Hylang. You won't get CL niceties: more language features, performance, standalone binaries, interactive debugger (all the niceties of an image-based development)…

I ended up using a fair bit of matplotlib through college and with colleagues. I too don't want to use python, but I also don't like throwing away its libraries, and I'm too lazy to invest in other* plotting ecosystems. In effect, I use up using matplotlib through py4cl/2.

Note that it is not my aim to replace the python ecosystem; I think that is far too lofy a goal to be of any good. My original intention was to interoperate with python through py4cl/2 or the likes, but felt that one needs a Common Lisp library for "small" operations, while "large" operations can be offloaded to python libraries through py4cl/2.

If performance is absolutely not a concern, then third option is using python libraries through py4cl/2. To put it differently, if calling python from lisp is not the bottleneck, then this is a feasible option.

I encourage people to try out Common Lisp because, unlike with Hy, you will get: speed, ability to build binaries, truly interactive image-based development (yes, more interactive than ipython), more static type checks, more language features (no closures in Hy last time I checked), language stability… To reach to Python libs, you have https://github.com/bendudson/py4cl My comparison of Python and CL: https://lisp-journey.gitlab.io/pythonvslisp/

> Not sure if such a thing already exists for CL

couple of solutions exist for this

https://github.com/bendudson/py4cl

https://github.com/pinterface/burgled-batteries

Ahh, makes sense. Well, if you ever wanna steal some of python's thunder, libpython-clj worked great for me lol. Supposedly py4cl fills a similar role in Common Lisp.