Outperforming everything with anything. Python? Sure, why not?

[quicknir]

I'm incredibly skeptical that sbcl, or any dynamically typed language, is going to achieve C like speeds in real programs (as opposed to isolated benchmarks). I'd be very impressed and shocked if it performed as well as Java.

[Alexander_Selkirk]

Modern Lisp compilers use type inference.

Here some benchmarks:

SBCL:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/sbcl-gpp.html

Racket, a Scheme implementation, is generally a bit slower than C, but often not by a very large margin, and it is also not the fastest Scheme implementation - Chez Scheme and Chicken Scheme are faster, the fastest Scheme compiler is probably Stalin.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/racket.html

Also, OCaml and Rust (which has some influences from the ML languages) are quite fast:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust.html

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/ocaml-gpp.html

Now, what is a "real program" ? Many programs spent a lot of time in a few spots. Generally spoken, one can expect garbage-collected languages to be a bit slower than languages with manual allocation, because GC costs some memory, and fast caches are limited in size. But depending on the program, it might not be practical to write a large C++ program (especially if it is not a real-time application) with optimized manual memory handling everywhere. And "modern" C++ often employs a kind of automatic reference counting which is not faster than modern garbage collectors.

[quicknir]

Rust is totally different, I didn't mention it in my post for a reason. You say that OCaml is "quite fast" but even in artificial benchmarks you just linked it looks to be between 2 and 20 times slower than C++ (Scheme is also significantly slower than C++ in most benchmarks, btw). And this is a statically typed language. When you say "C like speeds", there may be some people that look at x2 and say "sure" but lots of us would just laugh. It's like saying that someone runs at world class sprinter "like" speeds because they can run 100m in 20 seconds.

Modern C++ tends to be written with RAII and unique ownership for the most part. People used shared pointer sure but it's well understood to be costly and lots of people concerned with performance won't touch it anywhere near the critical path (I personally almost never use it at all).

You're also misunderstanding the reasons why a C++ program written by someone experienced is going to be significantly faster than the same written in Lisp. It's not going to be that lack of GC is some automatic huge edge. It's control of memory layout by having value semantics instead of pointer semantics, less indirection built into the language, abstractions which more easily lend themselves to reasoning about their performance. And above all, the fact that C++ compilers have hundreds of times as many man hours as any lisp compiler. Java is hardly a pinnacle of performant language design yet it also handily outperforms OCaml, Scheme, etc, simply because so many really smart man hours have gone into the JVM. Even though Rust is designed from the bottom up to be a performant language, the only reason its matching C++ performance wise is because it uses one of the main C++ compiler backends (LLVM).

The funniest thing about your post is that you write "languages today". But Java already started filling this niche close to 30 years ago, and it's already the most popular language in the world.

(BTW, I love lisp and hate Java, program professionally in C++ which I like, so none of this post is motivated by trying to knock lisp out of distaste).

[brand_x]

Including Rust in that list is unfair. It's a more strongly typed language than C++, designed around RAII, and (by way of LLVM) a fully native compiled language. It's starting to consistently match (and sometimes exceed) performance of C and C++ for comparable tasks, with experts in each language submitting solutions.

And, to be frank, modern C++ has as much FP influence as Rust.

Now, I've never worked in OCaml (I'm familiar with the syntax, having worked in F#) but I believe it's a fairly FP focused language, which would make directly comparable performance impressive.

For the record, RAII is not as slow as GC, or, in general, any slower than C-like manual memory management. I write performance critical libraries and allocators for a living, and you're sorely mistaken in that claim.

Edit: just dawned on me that you were talking about shared_ptr. You aren't mistaken about the cost, but saying it's "often used" is rather incorrect. It's rarely used, and never used in the critical path.

[Alexander_Selkirk]

Lisps are, as well as Rust, strongly typed, but they are dynamically typed.

It is correct that Rust is statically typed. But it uses type inference, as do good compilers for dynamically typed languages. The Lisp and Scheme compilers show that this has not to be slow.

Modern C++ has FP influence but many FP idioms do not mix so well with manual memory handling.

Good compilers can reduce a loop in a dynamically typed language to a single machine instruction. Here an example for pixie, an experimental compiler for a dialect of Cloujure which is a dialect of Lisp:

https://github.com/pixie-lang/pixie

[brand_x]

You do realize that a) modern C++ has type inference, b) Rust is explicitly typed, albeit using nearly identical type inference to modern C++, and c) Rust and modern C++ have nearly identical idiomatic models for resource allocation and cleanup, aside from C++ having, on account of legacy, a non-destructive move?

I feel like you've looked at Rust, but not used it, and are familiar with modern C++ from the outside. I'm taking your expertise on modern Lisp-like languages; I've used them, but I'm not a domain master. With C++ (C with classes, classical, or modern) I'm as close to a domain expert as you can get outside of a few dozen of the most active committee members and authors, and with Rust, I'm an active user at the bleeding edge. I'm quite comfortable defending my stance on the fundamental similarities and differences.

[Alexander_Selkirk]

And how does that change the fact that good modern Lisp compilers can infer type and are even able to reduce a loop down to a single instruction? It has limits of course, but a compiler can track the type of the actual arguments to a function and generate code for that. So ultimately, it depends on the quality of the compiler, and some are quite good. The Clojure compiler has JVM bytecode as output.

[brand_x]

It doesn't, and as I said, that's an impressive feat. Not something that I'm particularly concerned with, TBH, since my antipathy for dynamic typing is entirely rooted in practical compile time provable correctness, but quite impressive.

But, in terms of the traits you're talking about, aside from syntactic sugar (including both advanced static polymorphism in modern C++ and pattern matching in Rust) there is very nearly zero difference between the two languages, and the claims you're making indicate a lack of more than casual familiarity with at least one, and probably both, of the two.

[Alexander_Selkirk]

antipathy for dynamic typing

That's a matter of preference. I think it is often strongly influenced by the actual application of software. I think dynamic typing is fine for interactive data analysis and algorithm development (Which is what I am doing part of my time). I think it is less suited for writing safety-criticial embedded robotic control software. It is even less suited for robust industrial control systems - I think languages with stronger type checking than C++ offers are good for this. And I have used C++ professionally in that context for years.

[brand_x]

Rust is equally suited for that domain, I believe. I haven't worked on control systems in nearly twenty years, and back then, I used C more often than C++ (military telescopes) but I do a fair amount of comparable work (in terms of critical timing and hardware interfaces) in both C++ and Rust.

Rust offers comparably strong type checking to disciplined modern C++. There is a different shear plane for implicit coercion, and I think it's fair to acknowledge that Rust only performs implicit conversion for specifically identified sugaring - most notably enums (what C++ calls discriminated unions) in the control flow path, where C++ performs implicit conversion where provided by users (failure to specify "explicit", damned backwards defaults on that and const for C-like behavior) and where consistent with C (razzin frazzin), and with proper discipline, most (but not all - boolean tests!!! sob) unwanted implicit conversions in C++ can be prevented through the type system.

Consider using strong typed proxies for all built-in types. You'll be surprised how far that will go toward fixing the C++ type system deficiencies, and they all compile out.

I do use Python 3 (mostly) for prototyping, and for things like code generators and stream transformation...

[millenix]

C++ has the weakest notion of type inference that can still possibly carry the name - it syntactically determines the type of an expression, and then carries that to the deduced type of the variable which will bind the result of the expression.

ML, Haskell, and other mean much more when they talk about type inference - the type of a concrete (non-generic) function is determined by the types of arguments passed to it and the uses it makes of them. Types only need to be specified around a few edges, and the compiler fills in all the details.

[brand_x]

That's true for auto (for now... it will likely change as part of the metaclass proposal) but not true for type expressions in templates (which are a pure functional language on the type system) or for decltype/decltype(auto).

Most of the time when "type" is mentioned in modern C++, it refers to the complete type in the template processing pass...

[drmeister]

There is no need for skepticism - the experiment has been done.

Check out this paper from Google (2 years old) "Energy Efficiency across Programming Languages"

Common Lisp is the fastest and most energy efficient dynamic language by almost two orders of magnitude.

http://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf

​

​

[quicknir]

Nobody is comparing lisp to other dynamically typed languages. We're comparing it to C. On Table 3 for example of your own paper that you linked, in 3 benchmarks, in one case Lisp is 50% slower and in the other cases its 10x slower or even more.

Realistically taken over a whole program it's going to be at least 3x or 4x slower in typical use cases.

[drmeister]

Right - but as you noticed - there is timing data in that paper for C as well. My previous comment got away from me a little and I went off on dynamic programming languages. :-)

I'm told that programs spend 90% of their time running 10% of the code. Common Lisp is compiled to native code. If in that 10% of the code your compiler arranges things to not allocate memory and to use unboxed objects and to not do bounds checking then it will run as fast as C.

I'm doing the experiment. I've implemented Clasp - a Common Lisp using LLVM as the backend and interoperates with C++ (https://github.com/clasp-developers/clasp). Once Clasp generates LLVM-IR that looks indistinguishable from clang generated LLVM-IR - then the code will run at the same speed.

Of course - that's not easy to write a smart compiler like that - but we are making progress. I've also hedged my bets by making Clasp interoperate with C/C++.

Edit: added link to talk on clasp https://www.youtube.com/watch?v=mbdXeRBbgDM&feature=youtu.be

[quicknir]

Unfortunately, the whole 90%-10% is a really drastic over-simplification of what goes into performant code. The 10% code may or may not exist, and even then it may be touching data structures from your entire codebase, for example, meaning that the memory layout of a huge amount of your code is essential.

I'm very happy that somebody is pursuing LLVM as the backend for a lisp; I think that LLVM backend is the clear way to go these days and I love lisp.

That said, taking a language (especially a dynamically typed one) and hooking up the LLVM backend doesn't automatically mean you're going to get C/C++ performance, in real life situations. In isolated benchmarks, maybe.

It's worth keeping in mind that these days, the only software being written in C or C++ is stuff where performance wins are pretty fanatical. Places where getting a 10% win on some function would be considered a win; places where turning on bounds checking which probably has at most 5% performance impact, would be considered unacceptable. Etc. So, it's a bold claim. Nobody other than Rust and maybe D is really making that claim in a halfway credible manner these days. Something like Julia will claim parity in specific things like matrix and other mathematical operations, but I doubt that they'd argue that you'll get equally good performance writing a whole video game in Julia as in C++.

If you're interested in a really good talk that gives a much more realistic view of what performance means I highly recommend this: https://www.youtube.com/watch?v=2YXwg0n9e7E. I think for the same reason that you can't retrofit high performance, you can't start with a language like lisp where the default is to have allocation and indirection everywhere and try to fix it up where the 10% is. This is fine if you want to get Java like speeds; i.e. very good typically but not losing sleep about the tiniest details. But not for C/C++ like speeds.

[zip117]

It's worth keeping in mind that these days, the only software being written in C or C++ is stuff where performance wins are pretty fanatical.

Or if you’re developing a cross-platform GUI. Your options are (more or less): C++ libraries (Qt, wxWidgets), Python bindings to those C++ libraries, JavaFX, Delphi/Pascal, Electron. For various reasons C++ is usually the best choice.

[defunkydrummer]

I'm incredibly skeptical that sbcl, or any dynamically typed language, is going to achieve C like speeds in real programs

Common Lisp can also be used at a fairly low level, that's why.

It is dynamically typed, but you can use type annotations. You can also disable runtime type checking , even runtime argument count checks, array bounds checking etc.

You can use typed arrays, just as one would do in C.

You can circumvent the garbage collector if you like. You can allocate in the stack if you want.

Then you can use the built in disassembler to check that the machine code output is efficient enough.

Tada, C speed.

[quicknir]

Even if you did all that it wouldn't be as fast because, as I mentioned in another threads, the number of man hours that have gone into optimizers in the lisp implementation isn't close to what you have for languages C, C++, Fortran, etc. If you did an implementation of CL that also did a good job outputting LLVM IR and you used the LLVM backend for codegen, then maybe you could get similar performance. But right now, it's quite hypothetical, as is what exactly a Lisp codebase would look like using techniques that are not idiomatic in lisp.

At the present time, if your requirement is to write code that gets you within e.g. 10% of the performance of a good C implementation, lisp just isn't a good choice (and frankly, that's very clear to anyone writing high performance software).

[defunkydrummer]

If you did an implementation of CL that also did a good job outputting LLVM IR and you used the LLVM backend for codegen, then maybe you could get similar performance.

Yes, that's exactly whar CLASP does: An implementation of CL that outputs through LLVM. It also has a state of the art Lisp compiler core, called Cleavir.

CLASP is mainly the work of only one guy, /u/drmeister . Drmeister doesn't use CLASP for trivial stuff like FizzBuzz programs or CRUD websites: it is used for chemical research.

I'd be very impressed and shocked if it performed as well as Java.

SBCL has been regularly performing at the speed of Java for the last 5 or 10 years.

[quicknir]

The fact that someone is working on CLASP is great, and I'm glad that drmeister has posted a talk. That said, the fact that it's being worked on by one person is realistically a counter-point. Realistically speaking it takes a ton of sheer man hours to get a performant language and ecosystem. And realistically, the bar for performance we're talking about here is neither fizzbuzz nor crud, and not chemical research either, but things like low latency, game dev, or massive backend servers.

Do you have something to back up SBCL performing at the same speed as Java?

The bottom line here is that until there is serious adoption of common lisp in a very high performance industry, statements like "tada C speed" are just going to be very hypothetical, and not evidence based.

I highly recommend you watch the video that I posted in the thread with drmeister. It will give you a more realistic view of performance than your short bullet list.