4 ms·

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 dif

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.

pjmlp 7y ago
I have written plenty of them since C vs C++ on comp.lang.c were a thing. Once upon a time Common Lisp compilers were already good enough versus Fortran. https://people.eecs.berkeley.edu/~fateman/papers/lispfloat.pdf 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
- jstimpfle 7y ago
  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? https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/gcc-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/sbcl-gpp.html 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?).
  - jsjolen 7y ago
    >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?

pjmlp 7y ago

I have written plenty of them since C vs C++ on comp.lang.c were a thing. Once upon a time Common Lisp compilers were already good enough versus Fortran. https://people.eecs.berkeley.edu/~fateman/papers/lispfloat.pdf 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

jstimpfle 7y ago
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? https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/gcc-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/sbcl-gpp.html 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?).
- jsjolen 7y ago
  >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?