3 ms·

I can't help feeling that Common Lisp should be doing better, considering that it's a language where you can effectively tell the compiler "It's OK to store thi

by jcl 17y ago

I can't help feeling that Common Lisp should be doing better, considering that it's a language where you can effectively tell the compiler "It's OK to store this variable in a register". It's currently doing about the same as Mono, which IIRC doesn't JIT, and worse than Java. The king of dynamic language performance right now is LuaJIT, which crushes Perl, Python, and Ruby and performs admirably relative to Smalltalk and Scheme.

eru 17y ago
The quality of the individual programs plays a large role. E.g. GHC (Haskell) has made huge strides in the past thanks to better libraries and implementations for the benchmark, despite nearly the same compiler. On a side note, a lot of the benchmarks had to be reformulated after lazy languages got fast. As far as I know, a benchmark at this side prescribes which algorithm you should use. Haskell (and e.g. Clean) just ignored a lot of the baggage because it was not used any further.
- igouy 17y ago
  > despite nearly the same compiler As you don't say how far "in the past" maybe that's nonsense or maybe that's true. > a lot of the benchmarks had to be reformulated after lazy languages got fast That's nonsense. Programs for one benchmark - binary-trees - had to be rewritten because "this is an adaptation of a benchmark for testing GC so we are interested in the whole tree being allocated before any nodes are GC'd" and with lazy evaluation GC gobbles up nodes before the whole tree's allocated - http://shootout.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=clean&id=1#about http://shootout.alioth.debian.org/u32q/benchmark.php?test=bi...
  - jcl 17y ago
    I love the shootout, by the way. Thanks for maintaining it.
    - igouy 17y ago
      Thanks to those who contribute programs. Every week there are new programs, often from people who haven't contributed a program before. One of these days someone will find a way to make effective use of all the cores for n-body, maybe.
  - eru 17y ago
    Thanks for clearing that up. I wrote from my unreliable memory.

by jcl 17y ago

eru 17y ago

The quality of the individual programs plays a large role. E.g. GHC (Haskell) has made huge strides in the past thanks to better libraries and implementations for the benchmark, despite nearly the same compiler. On a side note, a lot of the benchmarks had to be reformulated after lazy languages got fast. As far as I know, a benchmark at this side prescribes which algorithm you should use. Haskell (and e.g. Clean) just ignored a lot of the baggage because it was not used any further.

igouy 17y ago
> despite nearly the same compiler As you don't say how far "in the past" maybe that's nonsense or maybe that's true. > a lot of the benchmarks had to be reformulated after lazy languages got fast That's nonsense. Programs for one benchmark - binary-trees - had to be rewritten because "this is an adaptation of a benchmark for testing GC so we are interested in the whole tree being allocated before any nodes are GC'd" and with lazy evaluation GC gobbles up nodes before the whole tree's allocated - http://shootout.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=clean&id=1#about http://shootout.alioth.debian.org/u32q/benchmark.php?test=bi...
- jcl 17y ago
  I love the shootout, by the way. Thanks for maintaining it.
  - igouy 17y ago
    Thanks to those who contribute programs. Every week there are new programs, often from people who haven't contributed a program before. One of these days someone will find a way to make effective use of all the cores for n-body, maybe.
- eru 17y ago
  Thanks for clearing that up. I wrote from my unreliable memory.