6 ms·

That's really cool that this guy thinks dynamic languages have the potential to be faster than C++. Maybe he can write a second article when they are actually f

That's really cool that this guy thinks dynamic languages have the potential to be faster than C++. Maybe he can write a second article when they are actually faster, with some properly done benchmarks or some valid technical examples.

eru 17y ago
Common Lisp is already quite fast and dynamic. And for the same number of hacker-hours spend in optimizing, you probably get a larger speedup. Also Python+C can be quite a fast combo. Fast to develop and fast to execute. Forth is also quite fast and dynamic, if you grok it. A lot of functional programming languages have also become quite fast in the last decade. While there are in a sense more fluid than C++, they are normally considered static (and not dynamic) languages. If you want to compare asymptotic speeds where programmer-hours invested goes to infinity, the lower level languages will probably always win. Like assembler, C or C++. For benchmarks see: http://shootout.alioth.debian.org/ http://shootout.alioth.debian.org/
- 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.
- UncleOxidant 17y ago
  OCaml does quite well against C++ in the shootout. OCaml's Functors and type inferrence are a big win over C++ templates. Yeah, the syntax takes some getting-used-to, but all in all the language seems to hang together much better than C++ (perhaps not saying much)
  - eru 17y ago
    I agree. I like Haskell's syntax better. But their syntaxen are nearly isomorphic for the most common stuff.
    - UncleOxidant 17y ago
      I'm finding OCaml's approach to be a bit more practical even if it isn't as pure as Haskell. Once in a while it's nice to be able to drop into an imperative style or even do some OO and OCaml lets you do all of that.
      - eru 17y ago
        Yes. Though Haskell allows imperative style (via Monads), too.
- dtf 17y ago
  I've found Python/C++ (via boost::python) to be a fantastic combo. There's also luabind which does similar lua/C++ two-step.
magv 17y ago
More than 10 years ago Jeffrey Mark Siskind posted micro benchmark [1] of his aggressively optimizing Stalin Scheme compiler versus then-current GCC. Stalin produced code 21 time faster than GCC. I do not know why this fact remains so little-known. [1] http://groups.google.com/group/comp.lang.lisp/msg/9801ba2edd839daf http://groups.google.com/group/comp.lang.lisp/msg/9801ba2edd...
- psranga 17y ago
  Note the comparison is to C, not C++. The runtime improvement came from aggressive inlining. I'm pretty sure that C++ code (which allows templates, function objects etc) can be written to do the same. Of course, then we'll get into discussions about whether the C++ code is "idiomatic", requires "wizardry" etc. The biggest win I see for JIT'd dynamic languages is their ability to optimize across source files. I wish C++ had the capacity to slurp in ALL of a project's C/C++ files and compile it one pass. In these days of 16G developer desktops, is this an unreasonable demand? :)
  - gchpaco 17y ago
    In fact C++ is usually slower than C because parsing and comprehending it is so damned hard that compiler writers are satisfied when they can get that far.
alaricsp 17y ago
That day may not be too far off... I hope ;-)

eru 17y ago

Common Lisp is already quite fast and dynamic. And for the same number of hacker-hours spend in optimizing, you probably get a larger speedup. Also Python+C can be quite a fast combo. Fast to develop and fast to execute. Forth is also quite fast and dynamic, if you grok it. A lot of functional programming languages have also become quite fast in the last decade. While there are in a sense more fluid than C++, they are normally considered static (and not dynamic) languages. If you want to compare asymptotic speeds where programmer-hours invested goes to infinity, the lower level languages will probably always win. Like assembler, C or C++. For benchmarks see: http://shootout.alioth.debian.org/ http://shootout.alioth.debian.org/

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.
UncleOxidant 17y ago
OCaml does quite well against C++ in the shootout. OCaml's Functors and type inferrence are a big win over C++ templates. Yeah, the syntax takes some getting-used-to, but all in all the language seems to hang together much better than C++ (perhaps not saying much)
- eru 17y ago
  I agree. I like Haskell's syntax better. But their syntaxen are nearly isomorphic for the most common stuff.
  - UncleOxidant 17y ago
    I'm finding OCaml's approach to be a bit more practical even if it isn't as pure as Haskell. Once in a while it's nice to be able to drop into an imperative style or even do some OO and OCaml lets you do all of that.
    - eru 17y ago
      Yes. Though Haskell allows imperative style (via Monads), too.
dtf 17y ago
I've found Python/C++ (via boost::python) to be a fantastic combo. There's also luabind which does similar lua/C++ two-step.

magv 17y ago

More than 10 years ago Jeffrey Mark Siskind posted micro benchmark [1] of his aggressively optimizing Stalin Scheme compiler versus then-current GCC. Stalin produced code 21 time faster than GCC. I do not know why this fact remains so little-known. [1] http://groups.google.com/group/comp.lang.lisp/msg/9801ba2edd839daf http://groups.google.com/group/comp.lang.lisp/msg/9801ba2edd...

psranga 17y ago
Note the comparison is to C, not C++. The runtime improvement came from aggressive inlining. I'm pretty sure that C++ code (which allows templates, function objects etc) can be written to do the same. Of course, then we'll get into discussions about whether the C++ code is "idiomatic", requires "wizardry" etc. The biggest win I see for JIT'd dynamic languages is their ability to optimize across source files. I wish C++ had the capacity to slurp in ALL of a project's C/C++ files and compile it one pass. In these days of 16G developer desktops, is this an unreasonable demand? :)
- gchpaco 17y ago
  In fact C++ is usually slower than C because parsing and comprehending it is so damned hard that compiler writers are satisfied when they can get that far.

alaricsp 17y ago

That day may not be too far off... I hope ;-)