6 ms·

C is the Mike Tyson of programming languages. There will never be another like it. It's simple, dangerous and fast. You can't beat C, but everyone will keep try

by _wldu 7y ago

C is the Mike Tyson of programming languages. There will never be another like it. It's simple, dangerous and fast. You can't beat C, but everyone will keep trying. It may beat itself in the end though as it's too rough for the modern world.

pjmlp 7y ago
"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
- dooglius 7y ago
  I wonder if Allen considered that there might be a reason people chose to use C, it's not as if they were forced into it. "Something where experts can really fine-tune without big bottlenecks" is not a requirement specific to operating systems. It's a bit ironic to think that the inability to run fancy optimizations is considered a problem with C when one of the most widely recognized flaws in the C ecosystem is the way mainstream compilers will exploit behavior that was labeled "undefined" just to support old obscure architectures, to run all kinds of crazy transformations.
  - pjmlp 7y ago
    The same reason people got to choose JavaScript or PHP years later, the platform's adoption, in this case UNIX.
    - jacquesm 7y ago
      I don't think that's true. When I came of age in programming there were lots of choices already but none that offered the balance of control and speed that C gave. It was a very easy choice; do I invest my next two decades in Assembly, Pascal (in several flavors), Modula-2, Forth, LISP (which required unobtainable computers at the time), Basic (compiled or interpreted) or C? UNIX had very little to do with it, only very few people were lucky enough to have access to UNIX machines but untold 100's of thousands had access to PCs or 8 bit micros. The first time I saw a UNIX machine it was an Acorn 'Unicorn' and it was so far ahead of what I could afford that it might as well not exist.
      - pjmlp 7y ago
        Sure it was, there were zero reasons to use C on CP/M, MS-DOS, Atari, Amiga, Mac. It was just another programming language fighting for developer eyes. On Windows and OS/2, although IBM and Microsoft decided to go with C for the underlying low level layers, C++ was the way to go for high level coding, C Set++, MFC. With Borland having Turbo Vision, OWL and VCL. Macs were Object Pascal territory, and when MPW got C and C++ support, PowerPlant C++ framework was the way to go. Epoch, BeOS and Symbian were also C++ territory. MS-DOS games were also adopting C++ via Watcom and its DOS extender. UNIX and the rise of FOSS, based on UNIX culture, were definitely the only reason.
        flohofwoe 7y ago
        IME C++ wasn't really a mainstream option until the second half of the 90's. BeOS choosing C++ for its operating system APIs was an extremely exotic choice at the time (same level of "exotic" as NeXT choosing Objective-C). And IMHO, at that time, before or around C++98, C++ didn't fix a single problem of C, but instead just added a lot of new ones (one could argue that this is still the case even today).
- jacquesm 7y ago
  That's a nice quote but it is also a bit nonsensical in that there has been plenty of work on optimizing compilers, also for C/C++ and a whole bunch of other languages. That quote was true for some time but running into the limits of CPU clock gains for single threaded tasks all those optimizations are more than valid once more, and as you've no doubt noticed there is a veritable run on multi-core solutions embedded deeply in the languages, of which this article illustrates one special case using a co-processor.
  - pjmlp 7y ago
    The point being that generated code from C compilers being always the one to beat is an urban myth. C compilers are only speed monsters thanks to almost 50 years of research in optimizing C and C++ compiler backends.
    - jacquesm 7y ago
      > The point being that generated code from C compilers being always the one to beat is an urban myth. Ok. > C compilers are only speed monsters thanks to almost 50 years of research in optimizing C and C++ compiler backends. Lots of those optimizations apply in one form or another to other languages as well. And... so which is it? Are C compilers fast and the thing to beat or did that research go nowhere? C is the speed benchmark because 'beating C' is what will get you a foot in the door. Being 'slower than C' is going to get your pet language booted out the door because: - companies tend to compete on speed of execution - the speed of the compiler itself is a major factor in turnaround time for the typical edit-compile-test cycle - nobody cares about security until they've been bitten hard. This is all very frustrating but it seems to - in my experience - accurately reflect priorities in lots of corporations. It is up to us to change that. See the title: it is about the speed of execution, and it uses one technology 'GPU' to challenge another 'CPU' and yet the accent is on which language was used.
OskarS 7y ago
I mean, Futhark certainly can. The whole point of Futhark is that it's a functional language that can run on GPUs. Futhark will beat the pants off of C for most any problem that is suitable for GPU computation, even if written in an entirely functional style. For CPUs, I'd like to introduce you to my good friend Fortran.
- gridlockd 7y ago
  That's an apples to oranges comparison, because Futhark needs to compete with C on the GPU (CUDA/OpenCL), not C on the CPU. That's what I'm missing from these benchmarks - how does it fare against a handwritten, competent implementation in those languages?
  - gilmi 7y ago
    https://futhark-lang.org/performance.html https://futhark-lang.org/performance.html
    - gridlockd 7y ago
      This is comparing against a high-level library (Thrust) that offers a comparable level of convenience. That's fair, but it tells you nothing about the performance gap introduced by these high-level abstractions.
      - Athas 7y ago
        There is also a comparison against HotSpot, which is a hand-written GPU program (albeit imperfectly). Futhark does not outperform expertly hand-optimised GPU code, but most of the GPU code found in the wild is hardly expertly hand-optimised. Futhark comes out on top surprisingly often, but can be solidly beaten for complex algorithms or clever implementations. See figure 8 in this paper for examples: https://futhark-lang.org/publications/ppopp19.pdf https://futhark-lang.org/publications/ppopp19.pdf
  - penagwin 7y ago
    Yeah this is what I'd like to see, Futhark vs Cuda. If your application is better suited for GPUs of course it'll be faster than C on the cpu. GPU mining and AI training are done on the GPU for a reason, and they of course beat "C" on the cpu.
popee 7y ago
C is Sparta! :-)
reikonomusha 7y ago
I’d call a language like Scheme simple. C—especially post ANSI—is veritably not simple.
shrubble 7y ago
Both lovers of C and its detractors should read the Turing award speech of Tony Hoare http://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf http://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf
- com 7y ago
  I found this an interesting and illuminating read, partially for how some of the basic concerns that we have for language tools like compilers were imagined into being and later internalised by us all, but also for the “fear and horror” around bounds checks.
laughingman2 7y ago
Rust.

by _wldu 7y ago

pjmlp 7y ago

"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

dooglius 7y ago
I wonder if Allen considered that there might be a reason people chose to use C, it's not as if they were forced into it. "Something where experts can really fine-tune without big bottlenecks" is not a requirement specific to operating systems. It's a bit ironic to think that the inability to run fancy optimizations is considered a problem with C when one of the most widely recognized flaws in the C ecosystem is the way mainstream compilers will exploit behavior that was labeled "undefined" just to support old obscure architectures, to run all kinds of crazy transformations.
- pjmlp 7y ago
  The same reason people got to choose JavaScript or PHP years later, the platform's adoption, in this case UNIX.
  - jacquesm 7y ago
    I don't think that's true. When I came of age in programming there were lots of choices already but none that offered the balance of control and speed that C gave. It was a very easy choice; do I invest my next two decades in Assembly, Pascal (in several flavors), Modula-2, Forth, LISP (which required unobtainable computers at the time), Basic (compiled or interpreted) or C? UNIX had very little to do with it, only very few people were lucky enough to have access to UNIX machines but untold 100's of thousands had access to PCs or 8 bit micros. The first time I saw a UNIX machine it was an Acorn 'Unicorn' and it was so far ahead of what I could afford that it might as well not exist.
    - pjmlp 7y ago
      Sure it was, there were zero reasons to use C on CP/M, MS-DOS, Atari, Amiga, Mac. It was just another programming language fighting for developer eyes. On Windows and OS/2, although IBM and Microsoft decided to go with C for the underlying low level layers, C++ was the way to go for high level coding, C Set++, MFC. With Borland having Turbo Vision, OWL and VCL. Macs were Object Pascal territory, and when MPW got C and C++ support, PowerPlant C++ framework was the way to go. Epoch, BeOS and Symbian were also C++ territory. MS-DOS games were also adopting C++ via Watcom and its DOS extender. UNIX and the rise of FOSS, based on UNIX culture, were definitely the only reason.
      - flohofwoe 7y ago
        IME C++ wasn't really a mainstream option until the second half of the 90's. BeOS choosing C++ for its operating system APIs was an extremely exotic choice at the time (same level of "exotic" as NeXT choosing Objective-C). And IMHO, at that time, before or around C++98, C++ didn't fix a single problem of C, but instead just added a lot of new ones (one could argue that this is still the case even today).
jacquesm 7y ago
That's a nice quote but it is also a bit nonsensical in that there has been plenty of work on optimizing compilers, also for C/C++ and a whole bunch of other languages. That quote was true for some time but running into the limits of CPU clock gains for single threaded tasks all those optimizations are more than valid once more, and as you've no doubt noticed there is a veritable run on multi-core solutions embedded deeply in the languages, of which this article illustrates one special case using a co-processor.
- pjmlp 7y ago
  The point being that generated code from C compilers being always the one to beat is an urban myth. C compilers are only speed monsters thanks to almost 50 years of research in optimizing C and C++ compiler backends.
  - jacquesm 7y ago
    > The point being that generated code from C compilers being always the one to beat is an urban myth. Ok. > C compilers are only speed monsters thanks to almost 50 years of research in optimizing C and C++ compiler backends. Lots of those optimizations apply in one form or another to other languages as well. And... so which is it? Are C compilers fast and the thing to beat or did that research go nowhere? C is the speed benchmark because 'beating C' is what will get you a foot in the door. Being 'slower than C' is going to get your pet language booted out the door because: - companies tend to compete on speed of execution - the speed of the compiler itself is a major factor in turnaround time for the typical edit-compile-test cycle - nobody cares about security until they've been bitten hard. This is all very frustrating but it seems to - in my experience - accurately reflect priorities in lots of corporations. It is up to us to change that. See the title: it is about the speed of execution, and it uses one technology 'GPU' to challenge another 'CPU' and yet the accent is on which language was used.

OskarS 7y ago

I mean, Futhark certainly can. The whole point of Futhark is that it's a functional language that can run on GPUs. Futhark will beat the pants off of C for most any problem that is suitable for GPU computation, even if written in an entirely functional style. For CPUs, I'd like to introduce you to my good friend Fortran.

gridlockd 7y ago
That's an apples to oranges comparison, because Futhark needs to compete with C on the GPU (CUDA/OpenCL), not C on the CPU. That's what I'm missing from these benchmarks - how does it fare against a handwritten, competent implementation in those languages?
- gilmi 7y ago
  https://futhark-lang.org/performance.html https://futhark-lang.org/performance.html
  - gridlockd 7y ago
    This is comparing against a high-level library (Thrust) that offers a comparable level of convenience. That's fair, but it tells you nothing about the performance gap introduced by these high-level abstractions.
    - Athas 7y ago
      There is also a comparison against HotSpot, which is a hand-written GPU program (albeit imperfectly). Futhark does not outperform expertly hand-optimised GPU code, but most of the GPU code found in the wild is hardly expertly hand-optimised. Futhark comes out on top surprisingly often, but can be solidly beaten for complex algorithms or clever implementations. See figure 8 in this paper for examples: https://futhark-lang.org/publications/ppopp19.pdf https://futhark-lang.org/publications/ppopp19.pdf
- penagwin 7y ago
  Yeah this is what I'd like to see, Futhark vs Cuda. If your application is better suited for GPUs of course it'll be faster than C on the cpu. GPU mining and AI training are done on the GPU for a reason, and they of course beat "C" on the cpu.

popee 7y ago

C is Sparta! :-)

reikonomusha 7y ago

I’d call a language like Scheme simple. C—especially post ANSI—is veritably not simple.

shrubble 7y ago

Both lovers of C and its detractors should read the Turing award speech of Tony Hoare http://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf http://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf

com 7y ago
I found this an interesting and illuminating read, partially for how some of the basic concerns that we have for language tools like compilers were imagined into being and later internalised by us all, but also for the “fear and horror” around bounds checks.

laughingman2 7y ago

Rust.