4 ms·

If anyone is looking for benchmarks, the most comprehensive comparison of scheme implementations can be found here: http://ecraven.github.io/r7rs-benchmarks/ben

If anyone is looking for benchmarks, the most comprehensive comparison of scheme implementations can be found here: http://ecraven.github.io/r7rs-benchmarks/benchmark.html http://ecraven.github.io/r7rs-benchmarks/benchmark.html

reitzensteinm 10y ago
Wow, Chez mostly beats out Stalin.
- Johnny_Brahms 10y ago
  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.
  - lomnakkus 10y ago
    > 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.
  - pjmlp 10y ago
    > 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.
    - Johnny_Brahms 10y ago
      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.
      - pjmlp 10y ago
        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.
        Johnny_Brahms 10y ago
        I see what you mean. I never did those gigs, so I wouldn't know. In hindsight I don't regret it :)
  - bitwize 10y ago
    > 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?
    - deleted 10y ago
      [deleted]
    - Johnny_Brahms 10y ago
      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.

reitzensteinm 10y ago

Wow, Chez mostly beats out Stalin.

Johnny_Brahms 10y ago
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.
- lomnakkus 10y ago
  > 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.
- pjmlp 10y ago
  > 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.
  - Johnny_Brahms 10y ago
    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.
    - pjmlp 10y ago
      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.
      - Johnny_Brahms 10y ago
        I see what you mean. I never did those gigs, so I wouldn't know. In hindsight I don't regret it :)
- bitwize 10y ago
  > 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?
  - deleted 10y ago
    [deleted]
  - Johnny_Brahms 10y ago
    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.