Hacker News Reader

Comment by dreamcompiler | Hacker News Reader

One big one is that Lisp is probably much faster. Common Lisp is AOT compiled to the metal so it starts up fast and runs fast. CL is often within a factor of 2 of C speed and dramatically faster than plain Python. I haven't used Julia but recent stories on HN suggest it's no speed demon.

View on HN

Lisp compilers also tend to be quite fast, compared to LLVM-based compilers (well, except for Clasp, which is a Lisp based on LLVM, but that project is aiming for tight integration with LLVM-based code compiled from other languages.)

On my desktop, SBCL will compile itself from source and run the small version of its test suite in 90 seconds.

I don't know which recent stories you're talking about. I have read only one story here recently, and it was about an outdated version of Julia. Compare these two:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Julia should be faster than CL for long running numerical computation at least (reaching C/Fortran speed for type-stable code) as it was designed for that purpose (plus the good GPU support and use of libraries like BLAS). But there is no AoT option yet so you'll have to deal with JIT, making it much slower for any shorter running scripts because of all the compilation, which makes CL speed much more consistent across tasks.

“It was designed for that” doesn’t justify a claim. Common Lisp is a general purpose language with excellent support for fast numerical code. In SBCL in particular you can even write assembly if you want to do crazy AVX stuff.

Likewise in CCL.

While it doesn't justify by itself, it means that this area will be constantly profiled and optimized tricks will be implemented to handle it better, like auto-simd, using multiple dispatch to detect optimal BLAS method for every matrix operation, implementing broadcast/loop fusion. Even matlab which will poorly handle almost anything is pretty competitive in numerical processing.

And saying CL is fast because you can write in assembly is like saying Python is fast because you can write in C. And while you can't write in assembly in Julia, you can go down all the way down to the LLVM (and intercept the compiler right between detecting types and compiling so you can rewrite every intrinsic with your new backend in a more flexible way than multiple dispatch) like they did with XLA.jl for TPUs and CUDANative for GPUs.

> And while you can't write in assembly in Julia

Julia allows inline LLVM IR, so this is technically possible, if a little awkward:

https://julialang.org/blog/2017/03/piday#π-via-inline-assemb...

Do you have any citation for this claim? The results from the programming language benchmark game[1] suggest that Julia is sometimes a bit faster than SBCL, one of the fastest lisp implementations, and sometimes a bit slower.

These benchmarks may not apply for every use case, but at least they suggest that Julia is roughly as fast as compiled Lisp.

From my perspective, Lisp falls into the third tier of programming language speed.

First tier (speed wise) of commonly used or discussed programming languages on HN are C++, C, and Rust. These have the performance for almost any task but require significant development effort.

Second tier languages trade off a bit of speed for other conveniences. These include Ada, C# and Java. Definitely slower than first tier, but easier to use in their own domains of use.

The third speed tier languages are many of my favorites, for example Swift, Go, Lisp, Racket, Julia, OCaml, Haskell, Javascript, and Dart. These are still fast enough for most situations and can be very productive.

I do a lot of programming in Python3 because it is just so expressive; speed wise, it occupies the forth tier with Ruby and Lua. The relative slowness isn’t a problem for many tasks and Python is really fun to program in.

Speed isn’t everything. While in grad school, for fun, I wrote a program to generate programming language parsers. Unfortunately, this was in 1974 using punched cards and the only language that I had access to was FORTRAN IV or assembly language—both very fast languages. I never got the program to a useful level of functionality (my goal was a LALR parser generator). If I had Python, it would have been a different story.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

There are multiple benchmarks, but it's hard to trust anything because of varying level of skill with each language (and also there is no point in creating unmaintainable code just for speed as you say, the ideal comparison would be with idiomatic performance aware code). Also Julia is probably on tier 3, but in math problems it targets tier 1 (similarly how to python drops down to tier 1 for ML but on a language level).

https://julialang.org/benchmarks/

https://news.ycombinator.com/item?id=19750507 (picked the discussion because combining the optimizations of two people CL got to Julia level, though Julia code is correctly written but not particularly optimized)

https://github.com/jonathanBieler/ScientificComputingBenchma...

https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (the more direct comparison)

Good points!

Reply on news.ycombinator.com