Maybe this will need C based highly optimized backend as well, however, the code looks very clean and beautiful to me. I hope someday differentiable programming becomes possible in common lisp.
If it's not not good enough, there are a few CL bindings and wrappers around BLAS and LAPACK.
A good one is Matlisp, which is available in QuickLisp.
Current generations tends to be unaware that once upon a time C compilers only generated turtle code, it was the investment into optimizing compilers and abuse of UB that made current compilers able to generate fast code.
On today's machines, I think you can expect to get more than 50% of performance from trivial compilation, compared to optimized code. Depending on workload you it can be 80-90%. (I have a small amount of experience, based on my own very shitty compiler, to back up that claim).
Even on machines from "once upon a time", where performance was more directly correlated with code size, it couldn't have been that bad, assuming the factor of 5. And also seeing the fact that C was used for systems development from the start.
And that's still ignoring (or at least contradicting) the common lore that "once upon a time", LISP was comparatively more inefficient than C than it is today!
And I don't believe that abuse of UB is important to generate fast code. After all, fast code doesn't necessarily contain UB.
Once upon a time Common Lisp compilers were already good enough versus Fortran.
https://people.eecs.berkeley.edu/~fateman/papers/lispfloat.p...
As for C's performance on the old days,
"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."
-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming
Nobody doubts that you can efficiently compile high-level LISP programs for certain specific problem domains. In some cases, you can even get an edge over the equivalent, ugly, C program.
But empirically, for general systems programming, C is second only to assembly in performance, the only problem being pointer aliasing (which you can easily avoid in many cases by using global data instead of doing overabstracted OOP).
That's not because C is perfect, but because it gives you the right mindset, and gives you control in a very accessible way. (And yes, of course you can write C-like systems code in LISP, too... If you're masochistic enough).
The benchmarks game should be enough of a proof here (and it's not even for complicated problems). Why don't you try improving SBCL times there and then come back?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
(Not that I care for performance factors of 4 that much by default. These are simple programs. And at least they refute the ludicrous claim that C is slow, right?).
Alright, but to what degree is the latter the cause of the former? The OP has already noted that C used to not be very fast, and that it became fast through the rise of sufficiently smart compilers. Do you dispute this claim?
>Why don't you try improving SBCL times there and then come back?
What good would that do? You have already seceded that you can write a C-like program in Common Lisp. This is especially true in SBCL, where you could write a Lisp program to generate the correct assembly code for the program.
I wasn't alive at that time... But as described I'd wager to dispute it. You need much more sufficient-smartness to make LISP fast. Isn't it obvious? Or is that somehow counter to any history you've read, except when cherry-picked and reinterpreted by some HN commenter?
> The OP has already noted that C used to not be very fast
Not very fast, compared to what? It's just not extremely fast when compared to numerical Fortran code (not: systems programming) or when compared to Assembly. Right? In my book this is just the worst kind of cherry picking.
If it was a reasonable claim, then would someone name the production OS from the early 70s written in LISP, and explain how it's better?
Better or more performant for some measure of performance? I mean, you can always read the UNIX hater's handbook if you're interested in qualities that UNIX did not possess decades ago.
>You need much more sufficient-smartness to make LISP fast. Isn't it obvious? Or is that somehow counter to any history you've read, except when cherry-picked and reinterpreted by some HN commenter?
If you want to make a pedantic argument, then no, it's not difficult to make Common Lisp potentially as fast as C. This is because I can very easily drop down to a level of safety which is on the same level as C. This is, of course, unsafe and I would never recommend it.
I don't understand why numerics performance is cherry-picking, but "systems programming" (what does that mean? OS dev. only?) is not.
This would be a much simpler discussion if you concisely describe in a semi-formal manner why C has a larger potential to be fast than CL. If you did so, it probably would be a lot more difficult for me or anyone else to refute your claims.
That's stating the obvious, which I had already stated in advance if you care to read it. (Don't miss the extra "If you're masochistic enough"). What you're presenting is a Turing tarpit kind of argument - totally irrelevant to anybody with a sense for practicality.
> Better or more performant for some measure of performance? I mean, you can always read the UNIX hater's handbook if you're interested in qualities that UNIX did not possess decades ago.
From what I remember, the Unix hater's handbook is half satire (based on good understanding), and half wrong. Yes, UNIX is the worst useable OS, except all the alternatives.
> I don't understand why numerics performance is cherry-picking, but "systems programming" (what does that mean? OS dev. only?) is not.
Because most programs aren't numerics programs, but every software system needs "systems programming". And coincidentally, C was made for systems programming. Unlike Fortran, it was not made specifically for numerics / scientific programming.
> This would be a much simpler discussion if you concisely describe in a semi-formal manner why C has a larger potential to be fast than CL. If you did so, it probably would be a lot more difficult for me or anyone else to refute your claims.
I suggest actually reading my comments, because I've written all that I have to say. In one sentence, the other side's arguments are all either of the sufficiently-smart-compiler kind, or the performance equivalent of the Turing Tarpit fallacy.
Just a last comment, we're kind of off the rails here. I'll read your reply but I won't answer, I hope you're OK with that!
> What you're presenting is a Turing tarpit kind of argument - totally irrelevant to anybody with a sense for practicality.
Not really, it requires very little to do so. Here's how to make fixnum arithmetic go wroom-wroom: https://plaster.tymoon.eu/view/1380#1380
Does that look like a Turing tar-pit to you? Scroll down to the assembly.
I mean, I do think that C-level safety is unacceptable though.
> [...] and half wrong. Yes, UNIX is the worst useable OS, except all the alternatives.
You happen to be misinformed regarding this. It's true today regarding Linux perhaps, but not back then.
>I suggest actually reading my comments, because I've written all that I have to say. In one sentence,
Didn't you just say that empirical evidence points towards C being fast? That's not enough.
And on 8 and 16 bit systems, any junior Assembly programmer could easily outperform code generated by C compilers.
It would surprise and nudge expectations in a positive way.
> You have already seceded that…
?
conceded ?
For information of anyone who doesn't know about performance of level 3 BLAS: It doesn't come just from vectorization, but also cache use with levels of blocking (and prefetch). See the material under https://github.com/flame/blis. Other levels -- not matrix-matrix -- are less amenable to fancy optimization, with lower arithmetic density to pit against memory bandwidth, and BLIS mostly hasn't bothered with them, though OpenBLAS has.
It's long been the case that compilers generate adequate vector code for five-year old cores. A large part of the wins for hand-vectorization (and assembly) come from targeting cores that haven't even been released yet, or were just made available.
Also, 2/3 is ... significantly worse than I would expect, actually. My experience writing GEMM (I did it professionally for a decade) is that getting to 80% of peak is mechanical, and the remaining 10-15% is where all the real work is.
It's also a mistake to ignore L1 and L2 BLAS; for data that fits in the cache hierarchy, these become important, and you can absolutely squeeze out significant gains from hand optimization. For the HPC community, such small problems are uninteresting, but for everyday consumer computing, you can reap huge benefits here.
http://www.iaeng.org/IJCS/issues_v32/issue_4/IJCS_32_4_19.pd...