ClojureScript and optimized C [video] | Hacker News Reader

ClojureScript and optimized C [video]

youtube.com

52 pointstosh15 comments

I think the problem is that it's using doubles, which JavaScript VMs feel free to optimise to ints. If I change the C code to long, I get the following:

   marcel@sarek[tmp]cc -Os sumints.c && ./a.out 
   49999995000000
    Elapsed time: 0.000031 millis

The original:

   marcel@sarek[tmp]cc -Os orig.c && ./a.out 
   49999995000000
   Elapsed time: 8.276664 millis

That's a factor 266989 difference, if anyone cares :)

Can you post your code, compiler, and the disassembly from main()? The only way I believe these numbers is if your compiler optimized the loop away to a constant.

That's exactly what it (clang) did.

You should update your YouTube comment too :)

Correct me if I'm wrong, but this is basically just timing how fast we can read and write to a single CPU register, so it's eliding all the memory bottlenecks that actually surface performance differences between native hotloops and JITed code.

Clojure on JVM is about 80x slower than ClojureScript in this scenario, by the way.

So Javascript compilers are faster than Java now?

Not really.

The code in question:

    (apply + (range 1e7))

is just summing a bunch of numbers. That's it. It's very easy to optimize for the sake of benchmarks.

It's way too trivial to use for any kind of meaningful real-world comparison.

I'm working on a cross-compiled library and I am able to compare the same code compiled for the JVM and for Javascript, the language used being Scala, which targets the JVM as a primary target and now we also have http://scala-js.org which is quite good btw.

I can tell you that the answer is definitely no, in my tests V8 being slower than the JVM by a factor ranging between 4 and 10.

If you're interested in seeing that in action, you can download the library's source code and run its tests for the JVM and see how that feels in comparison with the same tests being executed for JS. See: https://github.com/monix/monix

On my machine (2 yo MacBookPro), I get ~7 msec for the C version, 10 ms for PyPy, 35ms for CLJS, 240ms for Python 3.5, 300 ms for Python 2.7.

Nice comparison. Do you have a text version of the same benchmark?

[PS: Next time remember to submit the youtube.com version instead of the youtu.be, because youtu.be is autokilled.]

Here is the source: https://gist.github.com/mfikes/c531a4801a84e2c06af11588ce290...

The more I run the CLJS script, the longer it takes:

https://gist.github.com/sfermigier/9f60f01d1b4e8508a3a56bc42...

Any idea why ?

Probably just the parser getting tired.

In seriousness -- does this behaviour persist if you drop the computation into a `for` loop for a number of iterations instead of calling it manually every time?

I wonder if it's re-evaluating the previous statements up to that juncture each time, though that would be easy to test probs.

Reply on news.ycombinator.com