Comment by socialdemocrat | Hacker News Reader

Comment by socialdemocrat | Hacker News Reader

I cannot remember exactly when I discovered Julia or where. But I remember I got intrigued early on and wrote a blogpost about 9 years ago on Tumblr, which is still there comparing Julia to Ruby of all things: https://assoc.tumblr.com/post/70484963303/getting-comfortabl...

The normal thing today is comparing Julia to R, Matlab and Python. But my intro to Julia was actually trying to convert code examples in the O'Reilly book: "Exploring Everyday Things with R and Ruby: Learning About Everyday Things" to Julia.

I thought that worked quite nicely and that the Julia code looked a lot nicer than the Ruby code. It made me write a follow up blog post a few days later: https://assoc.tumblr.com/post/71454527084/cool-things-you-ca...

Unlike your typical Julia user I was always into programming because I wanted to make computer games. I liked playing with Game engine architectures and those exposed me to the problem of handling collision between objects of different types. Multiple-dispatch solves that problem very elegantly. Traditional object-oriented languages are pretty bad at it.

From the perspective of writing clean and expressive code, this really won me over to Julia early on before I had done much serious work with it.

It became my goto language for writing Unix tools, replacing Go, Ruby and Python.

For unix tools, I assume you mean command line tools? In which case how do you ameliorate the long startup time on each invocation?

Hehehe oh yeah, I almost forget about that because I stopped years ago bothering to actually make the tools into separate files that I start from the shell. It is more like Julia is my shell. I'll just have packages with common tools I use and launch them by calling functions from the REPL.

I'll just have packages for doing doing image file conversions in batch, modifying source code, changing configuration files etc.

Actually come to think about it, I used to have shell scripts in a pipeline to build an application for security. We had to obfuscate the source code and stuff like that. When I rewrote to Julia it all ran much faster. Even if there was a startup time, the workload was heavy enough that the higher performance of Julia easily outperformed bash.

Aren't many bash programs written in C? So this is implying Julia is somehow faster than C? Obviously that can't quite be true, but I can definitely imagine that the algorithms implemented in Julia could be fast faster than other algorithms - since the community has such a heavy influence of very hardcore mathematicians that have a string stress towards speed. Probably most of the algorithms in Julia are state of the art and push the boundaries on time complexity.

I was talking about bash scripts. But outperforming C with Julia is perfectly possible. Julia JIT compilation means you can remove overhead of a lot of function calls which C cannot do. A simple example would be sort taking a function pointer doing object comparison.

High level functional style code with things like map and filter can frequently be JIT compiled to optimal machine code.

Fortran is considered faster for numerical code than C and well polished Fortran libraries like BLAS is already getting outperformed by Julia.

For typical systems programming with need to tight control of memory and real time system C will still have the edge. But for anything crunching lots of numbers like data analysis or machine learning Julia will likely outperform everybody else.

Any reference to how Julia outperform Fortran in BLAS? I thought it is/was calling existing BLAS libraries?

Julia currently ships with fortran based Blas, but Octavian.jl is apure Julia matmul that is faster. (it's nowhere near finished though)

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

Thanks. But how LoopVectorization.jl is helping here, say comparing to C/Fortran optimized w.r.t. to the CPU? Is there somewhere in their doc mentioning this?

The basic answer is that LLVM doesn't do as good a job with some types of vectorization because it is working on a lower level representation. There are several causes of this. One is that LoopVectorization has permission to replace elementary functions with hand-written vectorized equivalents, another is that it does a better job using gather/scatter instructions.

Thanks! Very interesting.

Link here for others: https://octavian.julialinearalgebra.org/stable/

The list comprehension in your example is now type-stable without additional type-annotation so you can just write [x^2 for x in xs] and the compiler known that the results is a list of integers (for your example). There have been many improvements of this type in julia over the years (kudos to all who made this happen).

why ruby "of all things"? i've only dabbled a little in julia, but it definitely has a lot of the things i like about ruby, mixed in with a lot of the things i like about racket.

Not OP but I read the next sentence as explaining that sentiment:

> The normal thing today is comparing Julia to R, Matlab and Python.

I'm on the same page as you, though. I've never written R or any Matlab, but when Julia was still new, I remember seeing an example that it was a language that didn't use S-expressions, yet had as potent of macro and meta-programming abilities as if it did. Seemed like it'd be wonderful to work in.

Yeah it was stuff like that which attracted me to Julia I just did some meta programming to allow calling Objective-C from Julia using ObjC like syntax thanks to macros.

Most of the time multiple dispatch and a what really help abstracting your code and reuse.

I used to love how everything was an object with methods in Ruby, but now I have come to prefer the more functional Julia approach. Free functions compose so much better when doing functional style coding than methods on objects.

Reply on news.ycombinator.com