Live data from Hacker News

Ruby vs. Crystal Performance

ptimofeev.com

11–20 of 151 posts

Re: Ruby vs. Crystal Performance

#11
post #6

Here are thorough benchmarks of Crystal and C up against other interpreted languages: https://github.com/kostya/jit-benchmarks . It has other examples besides Fibonacci.

I'm quite surprised to see Javascript / Node so high up the ranks, quite impressive the amount of optimizations that's been done to the engine throughout the years.

Re: Ruby vs. Crystal Performance

#13
post #8

What’s the elevator pitch on Crystal? Seems like typed Ruby with performance considerations.

For a while, it was Ruby's ease of use with C's performance.

I believe that now they're trying to reduce marketing that relies on Ruby and present more as an independent language (which it is).

Re: Ruby vs. Crystal Performance

#14
post #6

Here are thorough benchmarks of Crystal and C up against other interpreted languages: https://github.com/kostya/jit-benchmarks . It has other examples besides Fibonacci.

Also same source, but more comparison against a wider variety of other languages and general benchmarks of data structures and algorithms: https://github.com/kostya/benchmarks

Re: Ruby vs. Crystal Performance

#15
This article by one of the Crystal developers explains why this comparison is not fair: https://crystal-lang.org/2016/07/15/fibonacci-benchmark.html.

> When doing operations between integers, Ruby will make sure to create a Bignum in case of overflow, to give a correct result.

> Now we can understand why Ruby is slower: it has to do this overflow check on every operation, preventing some optimizations. Crystal, on the other hand, can ask LLVM to optimize this code very well, sometimes even letting LLVM compute the result at compile time. However, Crystal might give incorrect results, while Ruby makes sure to always give the correct result.

Re: Ruby vs. Crystal Performance

#16
post #10
post #4

Earlier quoted context omitted.

I mean it's kinda trivial but it does have the added benefit of also showing off that it's statically typed. For a more real world example check out the website of Kemal (Crystals Sinatra equivalent) at https://kemalcr.com/ , where it benchmarks at ~46k requests per second in a HTTP benchmark vs 4k in Ruby.

Or something like Sidekiq in Crystal [1], which was 7 times faster. But now I wonder how much faster would Sidekiq run on TuffleRuby. [1] https://github.com/mperham/sidekiq.cr

I'd be amazed if TruffleRuby could beat Crystal, given the problems most JITs have had with Ruby. By restricting the extreme dynamism of Ruby a bit, Crystal can allow for optimalisations that no Ruby implementation will be able to match. It's just really difficult to properly compile languages where it's possible to dynamically redefine the + operator based on input from HTTP requests. That said, Truffle is looking super cool and Crystal does not have anything near the size and quality of the Ruby ecosystem yet.

Re: Ruby vs. Crystal Performance

#17

This article by one of the Crystal developers explains why this comparison is not fair: https://crystal-lang.org/2016/07/15/fibonacci-benchmark.html . > When doing operations between integers, Ruby will make sure to create a Bignum in case of overflow, to give a correct result. > Now we can understand why Ruby is slower: it has to do this overflow check on every operation, preventing some optimizations. Crystal, on t…

You may want to edit the link.

Re: Ruby vs. Crystal Performance

#19
post #17

This article by one of the Crystal developers explains why this comparison is not fair: https://crystal-lang.org/2016/07/15/fibonacci-benchmark.html . > When doing operations between integers, Ruby will make sure to create a Bignum in case of overflow, to give a correct result. > Now we can understand why Ruby is slower: it has to do this overflow check on every operation, preventing some optimizations. Crystal, on t…

You may want to edit the link.

Whoops. Thank you!

Re: Ruby vs. Crystal Performance

#20
post #5

The recursively written Fibonacci benchmark is terrible for comparing a interpreted language to a compiled language. When compiling with optimizations in C, for example, the compiler significantly transforms the program. [1] It's possible Crystal does too. [1] https://godbolt.org/z/vaESBG

Recursive fibonacci is highly artificial, but the fact that a compiler can greatly transform the program is an important advantage of compilers over interpreters.

I had the (mistaken) impression that the GCC code signicantly transformed the algorithm because there is only one recursive call instruction, but looking at it closer it's still exponential. I still think it's a pretty silly idea to use such an unrealistic benchmark. Especially since it might be possible to make a compiler turn the exponential algorithm linear.
Post reply on HN