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

Ruby vs. Crystal Performance

ptimofeev.com

Post reply on HN
Print view View original

71–80 of 151 posts

Re: Ruby vs. Crystal Performance

#71

Post by nv-vn »

zucker42 wrote: post #20
eeereerews wrote: post #7

Earlier quoted context omitted.

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.

I'd be very surprised if there's a commercial compiler that would automatically optimize this into linear time. Maybe some obscure functional research language? But certainly don't think LLVM is capable of dynamic programming.

Re: Ruby vs. Crystal Performance

#73

Post by remmargorp64 »

dwheeler wrote: post #32
chrisseaton wrote: post #28

Earlier quoted context omitted.

> Care to explain more? Having been using Ruby for about 8 years and Crystal for about 4, they actually have an extremely similar syntax and are also semantically very close. To the point where many Ruby scripts are completely valid Crystal, or at the very least require only a few changes. It doesn't have Kernel#eval. It doesn't have Kernel#send. It doesn't have Kernel#binding. It doesn't has Proc#binding. It doesn't…

Agreed. Crystal looks like it has many positive characteristics, but having similar syntax has nothing to do with having similar semantics. Without constructs like missing_method, you cannot run practically any of the Ruby ecosystem libraries, including everything involving Rails. Java and C also share a similar syntax, but that does not make that you can easily swap one for the other.

To be fair, method_missing has caused more nightmares and problems with debugging than probably any other feature in Ruby. I actively avoid using it, and even the Rails team has massively dialed back on its use in their libraries over the years...

Re: Ruby vs. Crystal Performance

#74

Post by laughinghan »

chrisseaton wrote: post #28
watzon wrote: post #27

Earlier quoted context omitted.

Care to explain more? Having been using Ruby for about 8 years and Crystal for about 4, they actually have an extremely similar syntax and are also semantically very close. To the point where many Ruby scripts are completely valid Crystal, or at the very least require only a few changes. I do think that people trying to compare Crystal to Ruby kind of miss the point though. Ruby as an interpreted language, even optim…

> Care to explain more? Having been using Ruby for about 8 years and Crystal for about 4, they actually have an extremely similar syntax and are also semantically very close. To the point where many Ruby scripts are completely valid Crystal, or at the very least require only a few changes. It doesn't have Kernel#eval. It doesn't have Kernel#send. It doesn't have Kernel#binding. It doesn't has Proc#binding. It doesn't…

>> and are also semantically very close

>Sorry I super disagree with this. They look similar. Dig into it just below the surface? Start to model it formally? Not at all.

I think you're missing the point. If 90% of Ruby code works in Crystal unmodified (even if it's because the standard library had to be rewritten from scratch), then the programmer experience may well be quite similar, regardless of how fundamentally different they are if you model them formally.

Are Newtonian mechanics and Einstein's theory of general relativity "similar"? If you model them formally, they look nothing alike. But in 99% of practical situations in every day life, and even in the most precise experiments we could conduct for hundreds of years, they're so similar we can't tell the difference.

Re: Ruby vs. Crystal Performance

#75

Post by remmargorp64 »

frizkie wrote: post #2

I'm excited to see Crystal grow - I think it has a lot to offer. I know it's not an intended consequence or a goal of Crystal's development, but you'd be surprised how easily plain Ruby maps to Crystal's syntax and method name choices. It can come in handy when you're looking for an easy performance boost.

Actually, I would argue that mapping Ruby's syntax and method name choices to Crystal has been a major goal in Crystal's development. It's practically in the tag line for the language, "Fast as C, Slick as Ruby"

Re: Ruby vs. Crystal Performance

#76

Post by htns »

timon999 wrote: post #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 t…

Since late last year crystal made overflow checking the default (https://crystal-lang.org/2019/09/23/crystal-0.31.0-released....). Dunno how it changed the benchmark.

Re: Ruby vs. Crystal Performance

#77

Post by squarefoot »

Crystal would benefit a lot if ported and packaged for ARM architectures. Those small embedded boards seem the best place to make use of a system language that produces tight and fast native executables. I know there's something for the Raspberry-PI+Raspbian, however I hoped there was an official port for other boards on a more generic distro such as Debian, Armbian or DietPI. Being a bootstrapped compiler (a compiler written in the same language it compiles) makes this even harder to accomplish.

Re: Ruby vs. Crystal Performance

#78

Post by Scarbutt »

hosh wrote: post #63
eggsnbacon1 wrote: post #49

Earlier quoted context omitted.

Metaprogramming doesn't need to have a performance impact. VM languages like Java, C#, and JS allow you do define and modify code at runtime JS you can redefine anything, Java support is pretty good, C# better support is coming with generators

Ruby's "metaprogramming" is something Java, C# and JS don't do well -- dynamically redefining things during runtime. Everything in Ruby, including literals and operators, can be redefined during runtime, because everything is an object, and every message passed to any object can be redirected, filtered, transformed ad hoc. It's not just classes can be modified. Specific objects can be modified. Well-crafted Ruby code…

Why did you have to move on?

Re: Ruby vs. Crystal Performance

#79

Post by shay_ker »

chrisseaton wrote: post #21

Crystal and Ruby do not even remotely have the same semantics. They look similar but the similarity is extremely superficial. The extra semantics that Ruby has have a massive impact on performance, for even the most optimising implementations. This is not a reasonable comparison if you do not consider the 'slick as Ruby' part. No runtime metaprogramming! The entire Ruby ecosystem is built on runtime metaprogramming!…

I agree that the comparison is unfair - but I think the larger point is that there are many simple bits of Ruby that can copy/paste to Crystal with an immediate performance boost. In fact, it'd be interesting to slowly re-write a Ruby codebase into Crystal.

Of course, harder than it sounds, lots of specifics to figure out.

Re: Ruby vs. Crystal Performance

#80

Post by megavolcano »

Huge ruby ran here. Ruby on Rails has been my day job for a decade, and it pays the bills well enough. Crystal has always been a curiosity to me, but I have never been as productive in any other language or framework as I have been with Rails. I dont' care if you're language is "ruby-like" or "go fast" - if I'm not as productive with it as I am with Ruby, I'm not gonna touch it.

Get back to me when there is Crystal on Rails.

Post reply on HN