4 ms·

>But empirically, for general systems programming, C is second only to assembly in performance,[...] and gives you control in a very accessible way. Alright, b

>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.

jstimpfle 7y ago
> Do you dispute this claim? 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?
- jsjolen 7y ago
  >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.
  - jstimpfle 7y ago
    > 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.
    - jsjolen 7y ago
      Hi! 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 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.
- pjmlp 7y ago
  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.
igouy 7y ago
> What good would that do? It would surprise and nudge expectations in a positive way. > You have already seceded that… ? conceded ?

jstimpfle 7y ago

> Do you dispute this claim? 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?

jsjolen 7y ago
>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.
- jstimpfle 7y ago
  > 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.
  - jsjolen 7y ago
    Hi! 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 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.
pjmlp 7y ago
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.

igouy 7y ago

> What good would that do? It would surprise and nudge expectations in a positive way. > You have already seceded that… ? conceded ?