[eplawless]

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.

[magv]

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/9801ba2edd...

[psranga]

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]

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.

[eru]

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/

[UncleOxidant]

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]

I agree. I like Haskell's syntax better. But their syntaxen are nearly isomorphic for the most common stuff.

[UncleOxidant]

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]

Yes. Though Haskell allows imperative style (via Monads), too.

[jcl]

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]

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]

> 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=bi...

[eru]

Thanks for clearing that up. I wrote from my unreliable memory.

[jcl]

I love the shootout, by the way. Thanks for maintaining it.

[igouy]

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.

[dtf]

I've found Python/C++ (via boost::python) to be a fantastic combo. There's also luabind which does similar lua/C++ two-step.

[alaricsp]

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