Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You should have read the entire article:

> How fast is Clojure at running your code once it finally has got going? ... Clojure is on average 4x slower than Java and 2x slower than Scala.

That's pretty freaking slow.



And about twice as fast as Erlang, 5x faster than Ruby, Python or PHP and 10x faster than Perl.[1]

It's all relative.

[1] http://shootout.alioth.debian.org/u64q/which-programming-lan...


Those benchmarks are fairly useless, because it doesn't compare idiomatic usage of those languages, but rather the capability of those languages to drop to low-level primitives and libraries.

I did an experiment once, testing out a simple web-service on the JVM and Scala (with Scalatra) yields the same performance as Java (with Jax-RS), while Clojure (with Noir) is only 2x to 3x as slow and JRuby (Sinatra) is only 4x-5x as slow as Java.


>>Those benchmarks are fairly useless, because it doesn't compare idiomatic usage of those languages...<<

You seem to be complaining that the programmers were not forced to write slow programs :-)

>>I did an experiment once...<<

And you used libraries.


No, I'm complaining that those benchmarks aren't mirroring the way developers actually write code.


What specifically do you think the difference is, and how do you know?


This is the same benchmark that is used in the OP. So if you object to the characterization of Ruby/Python/PHP vs Clojure, you can make the same objection regarding the characterization of Clojure vs C.


While interesting, those benchmarks are only useful if you implement something remotely similar to the actual benchmarks. Just glazing over them, they seem to be "unfairly" targeted at low-level languages.

That said, they are fun to look at. I just had a wtf-moment looking at this:

http://shootout.alioth.debian.org/u32/performance.php?test=n...

~20 seconds vs ~20 minutes??


This sums up my feelings for the benchmarks:

http://shootout.alioth.debian.org/u64q/benchmark.php?test=fa...

Note that the "alternative" Lisp SBCL and Java 7 programs both outperform Fortran.

Of course I agree with you on wtf-moments. WTF makes Ruby take an hour, and SBCL take 10 seconds? That's two orders of magnitude! But no matter, I imagine a more clever Ruby programmer could reduce that, or just call out to a native library.


>>Note that the "alternative" ...<<

A program that simply switched according the command line arg and then printed:

    3968050
    Pfannkuchen(12) = 65
:would also out perform :-)

>>I imagine a more clever Ruby programmer could reduce that...<<

Is "a more clever Ruby programmer" some kind of equivalent to "a sufficiently smart compiler"? :-)

>>or just call out to a native library<<

When is a Ruby program fast? When it's written in C ;-)


> A program that simply switched according the command line arg and then printed…

Of course making programs do less can improve speed, and a great way of doing that is compile-time computation via macros! You can finish the program before it's even run.

> Is "a more clever Ruby programmer" some kind of equivalent to "a sufficiently smart compiler"?

No, since we assume human intelligence here. :P As the Graphics Programming Black Book puts it in the Chapter 1 title, "The Best Optimizer is between Your Ears".

> When is a Ruby program fast? When it's written in C ;-)

I'm going to use this one.


I've spent enough time asking for programs for the benchmarks game in Ruby forums, to start to doubt whether the "more clever Ruby programmer" will ever come forward ;-)

Maybe "a more clever Ruby programmer" always drops-down to C?

Maybe there's only a more clever Rails programmer :-)


1) those benchmarks are only useful if...

Any benchmark is only useful if...

http://shootout.alioth.debian.org/dont-jump-to-conclusions.p...

2) "unfairly" targeted at low-level languages

Don't make "unfair" accusations -- say why you think that.

3) ~20 seconds vs ~20 minutes??

Did you mean vs ~20 hours?


> Don't make "unfair" accusations -- say why you think that

Because there seems to be a bias in selecting the problems solved in the benchmark games: to be "fair" they should be randomly selected from a pool of all possible problems solved with computer programs. Or, maybe, the frequency of these problems in the real world should be taken into account?

Of course, they're not actually unfair since they hide nothing. The error is in the interpretation, e.g. "My program will be faster if I write it in language X instead of Y."

The nice link you posted sums it up well: "Programming languages are compared against each other as though their designers intended them to be used for the exact same purpose - that just isn't so."

edit: Spelling..


1) "they're not actually unfair"

So don't say that they are!

2) "The nice link you posted sums it up well"

I agree - but then I wrote those words.

3) "there seems to be a bias in selecting the problems solved in the benchmark games"

You still haven't said anything that suggests they are "targeted at low-level languages".


1) I didn't .. 3) I did in GP


1) You implied "unfair" by opining on what they would have to do to be "fair"; and you said something less vague than "unfair", you said "unfairly" targeted at low-level languages. If you don't mean to say they are "unfair" then your words are going to confuse ;-)

3) GP? Your opining about "selecting the problems" doesn't support the claim "targeted at low-level languages" anymore than it supports the claim targeted at high-level languages :-)

As you noted the important thing to remember is that timing measurements are not promises, and they aren't general answers to the question - Will my program be faster if I write it in language X?


On the other hand, those languages do not have a pretension of being fast.


You can always match the speed of java in critical areas by disabling number boxing, adding type hints, and using the mutable versions of data structures. This is what prismatic did for their ML computation code: http://www.infoq.com/presentations/Why-Prismatic-Goes-Faster...


> That's pretty freaking slow.

I suppose in a vacuum it is indeed (assuming the measurements are general), but in my actual use the speed of Clojure has been more than sufficient. People like to view programming language speed as a black and white issue in the context of blog and HN posting, but in many uses runtime and startup speed considerations are only part of the puzzle.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: