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.
Another C hate post? It seems way overblown. When you compare trivial compilation of C code with optimized compilation, you would see maybe a factor of 5 in difference in code size.
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.
"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
Cherry picking and pulling the sufficiently smart compiler card. "floating point processing in lisp"... "automatic parallelization"... yeah
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?
(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?).
>But empirically, for general systems programming, C is second only to assembly in performance,[...] and gives you control in a very accessible way.
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?
>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.
> 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.
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.
C wasn't fast compared to many other high level compilers on mainframes, some of them still being sold by IBM and Unisys, which kept the original system languages instead of throwing it away and rewrite everything in C.
And on 8 and 16 bit systems, any junior Assembly programmer could easily outperform code generated by C compilers.
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.