Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is Clojure so slow?

martinsprogrammingblog.blogspot.de

Post reply on HN
Print view View original

71–80 of 97 posts

Re: Why is Clojure so slow?

#71

Post by gtrak »

Mitt wrote: post #28
rabidsnail wrote: post #10

Earlier quoted context omitted.

Vars already default static, so we just need to take better advantage of that in the compiler.

Yes, Clojure 1.4 defaults to static. However, a Var still needs to do an extra lookup at runtime. A Var does not directly point to the object that I want. And Vars have to be that way, this is their core feature. Clojure is a dynamic language, so they need to stay dynamic too. All code constantly assumes that the objects behind Vars will change. Let’s say we have `(defn foo [] 1)`. The caller of (foo) will first look…

The jvm can already inline non-final virtual method calls, so getters and setters are free. Are you sure that being able to specify 'static' is a win? Alternatively, you can just use the compile-time capabilities of the macro system to inline your constants as locals.

Re: Why is Clojure so slow?

#72

Post by igouy »

Jach wrote: post #69
gizzlon wrote: post #38

Earlier quoted context omitted.

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 na…

>>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 libraryWhen is a Ruby program fast? When it's written in C ;-)

Re: Why is Clojure so slow?

#73

Post by bitcracker »

ithkuil wrote: post #63
CountHackulus wrote: post #58

Earlier quoted context omitted.

That "JIT cache" you're talking about already exists. It's known as AOT, or "Ahead of Time" compilation. I forget how you enable it, but it's there.

if you mean clojure AOT, it precompiles clojure to jvm bytecode. Usually the term JIT in this context is used to describe the native code generated by the VM on the flight, not the on the flight VM bytecode generation performed by a higher level language like clojure. EDIT: sorry, probably your referred to http://publib.boulder.ibm.com/infocenter/java7sdk/v7r0/topic...

According to this link precompilation with AOT produces worse results than normal JIT execution. If so, what is AOT useful for?

"Da AOT-Code über verschiedene Programmausführungen hinweg bestehen bleiben muss, ist die Leistung von mit AOT generiertem Code nicht so gut wie die von mit JIT generiertem Code."

Re: Why is Clojure so slow?

#74

Post by gizzlon »

igouy wrote: post #61
gizzlon wrote: post #38

Earlier quoted context omitted.

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??

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

Re: Why is Clojure so slow?

#75

Post by bitcracker »

ww520 wrote: post #62
bitcracker wrote: post #40

It's an implementation problem of Java. I never understood why the JVM folks didn't get along to develop a JIT cache. That means the first time I start a Java program it would run normally slow. But from the second run on it would use the native cache and run immediately fast with native performance. That would eliminate many performance problems of Java. I know that there already is a solution which uses a Java serv…

Did you read the article? The majority of the Clojure startup time is spent on initializing the Clojure runtime. "spends 95% of the startup-time loading the clojure.core namespace (the clojure.lang.RT class in particular) and filling out all the metadata/docstrings etc for the methods. This process stresses the GC quite a bit, some 130k objects are allocated and 90k free-d during multiple invokes of the GC (3-6 times…

> The majority of the Clojure startup time is spent on initializing the Clojure runtime.

That's correct but even without this startup time Clojure is significantly slower than other functional languages. Look at SBCL and Racket in

http://shootout.alioth.debian.org/u32/which-programming-lang...

That doesn't mean that I don't like Clojure. I am even considering it for a business project. But Clojure is definitely unsuitable for small apps (shell scripts etc.)

Btw the benchmark listing doesn't take LuaJIT into account. This JIT is the fastest I have ever encountered, way ahead of JVM regarding startup time.

Re: Why is Clojure so slow?

#76

Post by igouy »

gizzlon wrote: post #74
igouy wrote: post #61

Earlier quoted context omitted.

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. T…

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".

Re: Why is Clojure so slow?

#77

Post by igouy »

wanderingmarker wrote: post #65

To Clojure-curious people: please ignore this article. It is misinformed. Others on this thread have pointed out that the Alioth benchmark takes startup time into account. Yes, this imposes a startup penalty on Clojure. More importantly, the implementations of each individual benchmark vary significantly in performance quality. High-performance Clojure requires a couple of tricks in type hinting, using unchecked arit…

>>"Otherwise, it measures JVM startup time, and then it measures how long it takes the JIT to achieve maximum optimization."Please take that Clojure mandelbrot program, make repeated timing measurements without restarting the JVM and then report how those times compare to cold start on your computer.

The mean "warmed" times for the Java mandelbrot program were actually slower than the reported cold start time for the same program.

http://shootout.alioth.debian.org/help.php#java

Re: Why is Clojure so slow?

#78

Post by rbanffy »

fauigerzigerk wrote: post #70
Retric wrote: post #68

Earlier quoted context omitted.

Each of those users would be running it 45 days sooner so that cancels out.

No it doesn't. Development time is a one off (for a given feature set). Usage is recurring, so savings in running time catch up and eventually dwarf development time. But I don't think this calculation makes much sense in the first place. It's simply not that linear and depends on many other things, for instance whether it's a throughput or response time problem, the relative value being the first to market versus be…

> Development time is a one off (for a given feature set)

Indeed. With a feature set dynamic enough, the lead will mount up.

Re: Why is Clojure so slow?

#79

Post by gcv »

igouy wrote: post #77
wanderingmarker wrote: post #65

To Clojure-curious people: please ignore this article. It is misinformed. Others on this thread have pointed out that the Alioth benchmark takes startup time into account. Yes, this imposes a startup penalty on Clojure. More importantly, the implementations of each individual benchmark vary significantly in performance quality. High-performance Clojure requires a couple of tricks in type hinting, using unchecked arit…

>>"Otherwise, it measures JVM startup time, and then it measures how long it takes the JIT to achieve maximum optimization." Please take that Clojure mandelbrot program, make repeated timing measurements without restarting the JVM and then report how those times compare to cold start on your computer. The mean "warmed" times for the Java mandelbrot program were actually slower than the reported cold start time for th…

Sure thing. I made it run for 4000 cycles twice. The first (cold) run took 2831.323 ms, and the warmed-up run took 2571.397 ms. About 10% faster.

Judging by the invocation noted at the bottom of http://shootout.alioth.debian.org/u64/program.php?test=mande..., the comments about Java in the FAQ do not apply to the Clojure code. The benchmark seems to have been invoked straight from the command line.

Re: Why is Clojure so slow?

#80

Post by Jach »

igouy wrote: post #72
Jach wrote: post #69

Earlier quoted context omitted.

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 na…

>>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 i…

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

Post reply on HN