[tokenrove]

An underlying point to this article that is still true is that C isn't inherently fast -- you have to work together with the compiler to make sure it generates what you want.

Why is this even worth pointing out? Well, in many languages communities (Common Lisp is a good example), the speed argument comes up, and it's pointed out that carefully working with the compiler (declares in all the right places and so on) makes the implementation competitive, and this is often dismissed as "too much work", ignoring the fact that even in C, there's no free lunch.

When one recognizes that good performance often requires a dialogue with the compiler, one starts to recognize that a criteria for performant language implementations is not "it's just like C" but rather "it's possible to tell the compiler to make this fast".

This makes many alternate languages viable choices for high-performance work (and eliminates some!), at least based on the current state of their implementations.

Imagine if as much work had gone into their compilers as has gone into the production C and Fortran compilers of today.

[pekk]

Except that the default, basic, recommended style for writing in C and writing in some other language X often produces very reasonably fast code in C, and horribly slow code in X. Which was the whole reason people advanced the argument that you need to use contortions to get X to generate code that even approaches the speed of normal, uncontorted C.

[pjmlp]

Except for the little fact that in the 80's and 90's most hobby coders still managed to write better Assembly than C compilers for home computers were able to generate.

C compilers are fast in modern times, because of the amount of industry money spent in writing C optimizers since the industry adopted it.

[slededit]

You can still write better assembly today. You just probably wouldn't be able to keep up the effort for the entirety of your code base.

[tokenrove]

I agree, although I think this is mostly cultural.

If we're only talking about single-threaded, CPU-bound code, this is basically true of any imperative language without fancy data structures: even a fairly naive native compiler will produce "pretty fast" code in our modern times where the standard for pretty fast is pretty low.

It seems intuitive that the further a language is from the machine, the harder the compiler has to work to make that language's idiomatic constructs efficient on a machine.

The kicker here is that C is no longer so close to the machine. It's still a PDP-11, and today's machine is not. This idea is what I think is still useful about the original article, for all its other faults.

I admire compilers like MLton that actually deliver on the promise of higher-level languages without the usual performance compromises for abstraction. Hopefully we'll see more of this as time goes on, as well as more languages like Sequoia that are close to the new machine.

[zeta0134]

I imagine this is why so many game studios choose to use a mix of the two. C or C++ is used to write the engine code, which is kept just as simple as possible and is in charge of doing all the fiddly bits with the hardware. Unless you're on an embedded system with limited resources though (where the size of your code can actually matter) everything else is usually done in some sort of scripting language with its own reasonably fast JIT. This is possibly sub-optimal, but it enables really fast iteration on the parts of the code that need to change and go through rapid test cycles.

Deciding when to spend the energy and resources to optimize that one routine is the result of good benchmarks and code profiling. Identify your bottlenecks, and optimize the hell out of those. For everything else though, you need to ship a product, and the human effort is largely wasted on a less-called routine that makes the character blink every 173rd frame.

[dmytroi]

Yeah, but there is no "fast JIT" on iOS and PS4 (not sure about X1) at least because they forbid creating memory pages with "Executable" bit, so usually AOT compilation is still ftw in game dev.