If we look at the benchmarks where one can expect stalin to be fast (numeric, and more specifically floating point benchmarks.) stalin is really in it's own league.

The puzzle benchmark is nice, since it benchmarks many common compiler optimizations - with code written to be easily optimized. Stalin of course wins.

The other benchmarks are written in a more general style, which I have found does not always produce the best output with stalin. If I would spend some time optimizing these benchmarks, I could probably make Stalin come out on top a lot more often.

That, however, takes you are back to the old problem: A heavily optimized C program looks like C. A heavily optimized [insert functional programming language here. Most often haskell] program looks like shit.

What impresses me the most about chez is that it takes idiomatic scheme code, and produces neat and fast machine code.

> A heavily optimized C program looks like C.

Really? I haven't found that to be the case very often.

> A heavily optimized [insert functional programming language here. Most often haskell] program looks like shit.

Here we definitely agree :). It's also worth mentioning that it's not often worth it to optimize very much of your code. (The 80-20, or perhaps 95-5, rule applies in full force.)

Obviously, it's still worth it to have compilers optimize idiomatic code.

> A heavily optimized C program looks like C.

Not in the 80's and early 90's.

What C has, is 40 years of development effort invested by several multinationals with deep pockets and researchers, improving the optimizer algorithms of their compilers.

Well. Fast c doesn't look quite like regular C, but seeing C optimised for speed isn't rare.

Looking at older C code is still better than seeing the hoops people jump through to get [insert programming language] to run at regular C speeds.

Fast C usually doesn't include weird workarounds for things like Implementation-specific GC quirks or bending language semantcs to force it to do what you want.

No, fast C in the 80's and early 90's meant writing code that was actually like this:

    naked void my_C_func()
    {
      asm {
       ...
      }
    }

Which basically meant using C as a poor man's macro assembler and nothing to do with what ANSI C is.

There were also other tricks related to unions and bit fiddling.

In those days, on 8 and 16 bit home computers, C was seen like managed languages are nowadays.

I see what you mean. I never did those gigs, so I wouldn't know. In hindsight I don't regret it :)

> That, however, takes you are back to the old problem: A heavily optimized C program looks like C. A heavily optimized [insert functional programming language here. Most often haskell] program looks like shit.

Couldn't that be explained by observing that C looks like shit, and we've just gotten so used to the look (and the smell!) that we fail to notice?

Let me rephrase: for some types of problems it is easier to use an imperative language, because it is easier to express the fastest way of doing it imperatively.