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

51–60 of 151 posts

Re: Ruby vs. Crystal Performance

#51

Post by YorickPeterse »

eggsnbacon1 wrote: post #49
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!…

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 meta-programming capabilities is why optimising Ruby is so darn difficult. It's extremely powerful, but also complicates a lot of things.

Re: Ruby vs. Crystal Performance

#53

Post by ken »

eeereerews wrote: post #7
zucker42 wrote: 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.

That's sort of true, in the abstract, but it wouldn't explain what's going on here. Even JavaScript (with a JIT, but not a separate compilation step, and certainly no type annotations) is faster at this than compiled Crystal. There's clearly other factors which are much more significant than simply having a compiler.

Re: Ruby vs. Crystal Performance

#54

Post by kipply »

eggsnbacon1 wrote: post #49
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!…

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

On top of Ruby metaprogramming being unique, V8 and Hotspot are amazing premium deluxe engines that have had more time and/or resources.

Re: Ruby vs. Crystal Performance

#55

Post by aardvark179 »

eggsnbacon1 wrote: post #49
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!…

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

Metaprogramming definitely has a cost, but it's one that you can minimise if you have the ability to either invalidate and recompile code at run time, or if you can perform extensive whole program analysis when ahead of time compiling.

The more extensive the meta programming you can do, the more work it is to implement this under the scenes. For example in Java you can change the visibility of fields, and you can load new classes, so that's not too hard to take account of, but in Ruby you can redefine methods, add refinements so they behave differently depending on where they are called, or radically change the inheritance hierarchy. Implementations like TruffleRuby can maintain high performance even with these features being used, but it's taken a lot of work to achieve that.

Re: Ruby vs. Crystal Performance

#56

Post by hosh »

The thing I like about Crystal is that I can generate statically-linked binaries and distribute them. I can quickly build utilities for people to use and don't have to distribute the runtime. The type system wasn't as bad as I thought (especially with type inferencing). Having written Ruby professionally for 14 years, Crystal was relatively easy to pick up. There are a many libraries that hew closely to their Ruby counterparts.

There are some amazing things I love about Ruby, like the metaprogramming and monkeypatching ... but I have moved on. I do my server work with Elixir these days.

Re: Ruby vs. Crystal Performance

#57

Post by nine_k »

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

Ruby has to have runtime metaprogramming because it has no other time but run time.

Compile-time metaprogramming is way safer and more performant, but for it you need a compiler.

Re: Ruby vs. Crystal Performance

#59

Post by joelbluminator »

qeternity wrote: post #48
nicoburns wrote: post #35

Earlier quoted context omitted.

Yeah, a lot of people don't realise that JavaScript performance is closer to Java than Python, even though the semantics are much closer to Python.

We recently finished our first node backend (typescript) and I have to say it was an amazing experience. The npm ecosystem definitely attracts its fair share of undesirables, but I struggle to see why JS full stack isn’t the default for 99% of people.

Lots of people are sure their stack provides an amazing experience, for example I don't get why you would choose node over rails. As for the performance: looks good for js, but quite a memory hog or am I missing something?

Re: Ruby vs. Crystal Performance

#60

Post by eggsnbacon1 »

YorickPeterse wrote: post #51
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 meta-programming capabilities is why optimising Ruby is so darn difficult. It's extremely powerful, but also complicates a lot of things.

I reason the difference is mostly when metaprogramming can happen. In Java, redefining or adding code is very explicit, it can't just happen whenever. Same with C#. And there are lots of rules. A class can't modify itself, and there's limits to what changes you can make. And to make changes you must have control over the "classloader" that loaded that code.

JS on the other hand can do most of what ruby does, to my knowledge. Objects are key value pairs so you're free to mess with them in virtually any way you please. You can also mess with the inheritance by altering JS prototype chains.

I don't think metaprogramming itself has much to do with the speed of Ruby, with my admittedly limited knowledge of this stuff

Post reply on HN