Live data from Hacker News

Our experience using Clojure to speed up Beanstalk

blog.beanstalkapp.com

51–60 of 75 posts

Re: Our experience using Clojure to speed up Beanstalk

#52
post #43
post #39

Earlier quoted context omitted.

You've made a bunch of claims without showing any evidence to support them. Please point to specific examples we can all look at on the website which show -- "Programs are not meant to be..." -- which show -- "They are meant to resemble the C implementation." etc

I'm not going to back up these claims in any other way than pointing the "interesting alternative" programs that appear in some comparisons, which tend to be faster than the chosen versions. For example here: http://shootout.alioth.debian.org/u64q/benchmark.php?test=fa... Both Lisp and Java alternatives are faster than the "fastest" solution (written in Fortran). Finding any more support for the years-old opinion I v…

So we can immediately dismiss your "Programs are not meant to be written in idiomatic language. They are meant to resemble the C implementation." claims as baseless.

The only example you chose shows programs that manually unroll loops are not accepted. (And that's stated explicitly on the Help page. http://shootout.alioth.debian.org/help.php#unroll)

Re: Our experience using Clojure to speed up Beanstalk

#54
post #48

Earlier quoted context omitted.

And because of what then?

other tokens like #{ ^{ #() ~@ #_ #^ #'x ˆ:x

Clojure does have more sugar than Scheme, but imho some of it improves readability; for example, using brackets for grouping instead of overloading lists like Scheme does can make code easier to scan, because when you see parens in Clojure there are fewer meanings to choose from (usually only function application or a list literal). Example:

Scheme

  (let ((x 2) (y 3))
    (let ((x 7) (z (+ x y)))
      (* z x)))
Clojure

  (let [x 2 y 3]
    (let [x 7 z (+ x y)]
      (* z x)))
I think the Clojure version is easier to read without a paren-matching editor, though Scheme's rigorous minimalism does have its charm.

Re: Our experience using Clojure to speed up Beanstalk

#55
post #48

Earlier quoted context omitted.

And because of what then?

other tokens like #{ ^{ #() ~@ #_ #^ #'x ˆ:x

Pedantic note: #^ for metadata has been deprecated for at least 2 if not 3 versions. ^{ and ^:x aren't special. It's just ^ (reader metadata symbol) followed by a map and keyword respectively. Other things can also be metadata (for instance you can tag something with a classname to indicate a type hint).

You also missed out a few of the syntax quote stuff.

So, other tokens are #{} ^ #() #_ #'x ` ~ ~@

Full details: http://clojure.org/reader

Re: Our experience using Clojure to speed up Beanstalk

#56
post #40

This is more about the Ruby VM being much slower than the JVM than anything to do with Clojure. It would be somewhat interesting to see how JRuby 1.7 running their Ruby code but using the Java libraries would fare.

JRuby is still going to be slower than clojure, due to the semantics of ruby. All function calls are resolved at runtime, while clojure resolves as many as possible at compile time. Foo::Bar.method() vs (foo.bar/method) The ruby version does three loads from the heap, at runtime, while clojure does zero. invokedynamic in JDK 7 will help narrow the gap, but the fact remains that Clojure was designed with more performa…

I don't think this is quite right, although I'd be delighted to be corrected. Clojure still has to deref the var in order to call the function, and afaik this happens at runtime (hence the fact that you can redefine a function in the REPL).

Re: Our experience using Clojure to speed up Beanstalk

#58
post #54

Earlier quoted context omitted.

other tokens like #{ ^{ #() ~@ #_ #^ #'x ˆ:x

Clojure does have more sugar than Scheme, but imho some of it improves readability; for example, using brackets for grouping instead of overloading lists like Scheme does can make code easier to scan, because when you see parens in Clojure there are fewer meanings to choose from (usually only function application or a list literal). Example: Scheme (let ((x 2) (y 3)) (let ((x 7) (z (+ x y))) (* z x))) Clojure (let [x…

[deleted]

Re: Our experience using Clojure to speed up Beanstalk

#59
post #56
post #40

Earlier quoted context omitted.

JRuby is still going to be slower than clojure, due to the semantics of ruby. All function calls are resolved at runtime, while clojure resolves as many as possible at compile time. Foo::Bar.method() vs (foo.bar/method) The ruby version does three loads from the heap, at runtime, while clojure does zero. invokedynamic in JDK 7 will help narrow the gap, but the fact remains that Clojure was designed with more performa…

I don't think this is quite right, although I'd be delighted to be corrected. Clojure still has to deref the var in order to call the function, and afaik this happens at runtime (hence the fact that you can redefine a function in the REPL).

In recent versions of Clojure, vars are not by default dynamically bound.

Re: Our experience using Clojure to speed up Beanstalk

#60

I wonder how much of the speed change came from the difference in languages versus the difference in experience when writing both. The ruby version was written prior to the clojure one and so anything that was learned about git/programming during the ruby writing would haven be available during the clojure writing. I can believe that clojure would be faster; using concurrency well guarantees this somewhat. I still wo…

According the article, they were using ruby to bridge to a svn module that had git capability. They replaced that module with a native git library, called from Clojure. In summary: benchmark, profile, find hotspots, optimize. Works in every language. >:3

Sorry if it sounded confusing, but we had two modules: one for svn, one for git, there was no intersection between those.

But I agree, we've used Clojure(and JVM) in exact point where it would bring the most speed up to our app.

Post reply on HN