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

Rust is Not so Hairy

nevi.me

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Rust is Not so Hairy

#21

Post by nazka »

nevi-me wrote: post #13
sanxiyn wrote: post #8

Earlier quoted context omitted.

Yup, Java is fast, but OP shared that Rust used 7 MB to do the same thing for which Java used 240 MB.

From looking at the traces, the performance difference between the two is minimal (on a per op basis). This mainly because both the Java and Rust services don't do much beyond interfacing with Redis/Tile38. The impressive and important thing is the amount of resources used in performing their tasks. With a little math you can see that I have 64GB RAM, which is plenty. What remains scarce is CPU cycles, so if I can do…

Nice post. I will be really curious to see the same microservice done with Go and compare all of them.

Re: Rust is Not so Hairy

#22

Post by nevi-me »

nazka wrote: post #21
nevi-me wrote: post #13

Earlier quoted context omitted.

From looking at the traces, the performance difference between the two is minimal (on a per op basis). This mainly because both the Java and Rust services don't do much beyond interfacing with Redis/Tile38. The impressive and important thing is the amount of resources used in performing their tasks. With a little math you can see that I have 64GB RAM, which is plenty. What remains scarce is CPU cycles, so if I can do…

Nice post. I will be really curious to see the same microservice done with Go and compare all of them.

My Go is very basic, but I can follow up with a Go impl and compare it with Rust. The code shouldn't take an experienced Go programmer more than an hour, as it's mainly mapping gRPC calls to Redis calls.

Re: Rust is Not so Hairy

#23

Post by majewsky »

> Using protobufs meant deferring learning the various serde's of Rust, which has helped me to focus on getting something done.

I have only dabbled once with Serde to generate some JSON, but I found it quite pleasant to use. Similar to Go's JSON library: You basically annotate your types like "this struct can be serialized, the field FooBar is serialized as 'foo'" etc., and Serde generates a serialize method for you (or, to be precise, it generates an implementation of some Serialize trait for your type).

Re: Rust is Not so Hairy

#24

Post by nevi-me »

majewsky wrote: post #23

> Using protobufs meant deferring learning the various serde's of Rust, which has helped me to focus on getting something done. I have only dabbled once with Serde to generate some JSON, but I found it quite pleasant to use. Similar to Go's JSON library: You basically annotate your types like "this struct can be serialized, the field FooBar is serialized as 'foo'" etc., and Serde generates a serialize method for you…

It was less about JSON, but more about reducing the number of libraries that I had to learn in one go. The benefit of using protobufs/gRPC was that I already had a host of microservices that I could choose to interact with.

I'll need to learn serde at some point, but it might be after a while as all the things I'm planning on doing with Rust include protobufs.

Re: Rust is Not so Hairy

#25

Post by dbaupp »

pjmlp wrote: post #20
littlestymaar wrote: post #12

Earlier quoted context omitted.

Being “statically-compiled” isn't some magic property that automatically makes program run faster. It can even be the opposite in some situations, since you can't benefit from JIT optimizations. What makes Rust, like C or C++, efficient is not just that they are statically compiled, it's that they have massively-tuned optimizing compiler spending a lot of time in compile-time optimizations. If you take Go, another st…

> What makes Rust, like C or C++, efficient is not just that they are statically compiled, it's that they have massively-tuned optimizing compiler spending a lot of time in compile-time optimizations. Actually lots of money spend across compiler vendors in the last 30 years, and UB abuse, as C compilers were pretty lame in the early 80's.

There was no need to "well actually" that, as it is the same point the parent was making: that money (and UB abuse) is why the tuned compilers now exist.

Re: Rust is Not so Hairy

#26

Post by pjmlp »

dbaupp wrote: post #25
pjmlp wrote: post #20

Earlier quoted context omitted.

> What makes Rust, like C or C++, efficient is not just that they are statically compiled, it's that they have massively-tuned optimizing compiler spending a lot of time in compile-time optimizations. Actually lots of money spend across compiler vendors in the last 30 years, and UB abuse, as C compilers were pretty lame in the early 80's.

There was no need to "well actually" that, as it is the same point the parent was making: that money (and UB abuse) is why the tuned compilers now exist.

I interpreted differently, as if being an inherent property of how C and C++ were designed.

Re: Rust is Not so Hairy

#27

Post by geezerjay »

nevi-me wrote: post #2

A few people asked me about my experiences with Rust after I mentioned seeing significant performance improvements. I wrote a blog post about it and open sourced both the Java and Rust code.

Thank you for writing the article. It's very interesting and a pleasant read. Kudos!

Re: Rust is Not so Hairy

#28

Post by geezerjay »

pjmlp wrote: post #20
littlestymaar wrote: post #12

Earlier quoted context omitted.

Being “statically-compiled” isn't some magic property that automatically makes program run faster. It can even be the opposite in some situations, since you can't benefit from JIT optimizations. What makes Rust, like C or C++, efficient is not just that they are statically compiled, it's that they have massively-tuned optimizing compiler spending a lot of time in compile-time optimizations. If you take Go, another st…

> What makes Rust, like C or C++, efficient is not just that they are statically compiled, it's that they have massively-tuned optimizing compiler spending a lot of time in compile-time optimizations. Actually lots of money spend across compiler vendors in the last 30 years, and UB abuse, as C compilers were pretty lame in the early 80's.

> UB abuse

That baseless assertion makes no sense. UB is a property of the ISO standard and has no effect on how compiler vendors implement the language. In fact, UB is intended to enable vendors to be free to choose how they implement that behavior. So why do you believe that the freedom to pick how you implement something hinders any development effort?

Re: Rust is Not so Hairy

#29

Post by nevi-me »

geezerjay wrote: post #27
nevi-me wrote: post #2

A few people asked me about my experiences with Rust after I mentioned seeing significant performance improvements. I wrote a blog post about it and open sourced both the Java and Rust code.

Thank you for writing the article. It's very interesting and a pleasant read. Kudos!

Thanks! Someone suggested I also create the same with Go, I'm going to give it a bash in the coming days.

Re: Rust is Not so Hairy

#30

Post by stefs »

nadioca wrote: post #11
pjmlp wrote: post #10

Earlier quoted context omitted.

If you are talking about free Java compilers that is correct. Most commercial compilers, specially those for embedded markets always had AOT native code as deployment option. But now the bad Oracle is finally making the AOT compiler research they got from Sun Labs available for free.

How does it compare against c/c++ in terms of performance ?

the native executables native-image generates are usually a bit slower than hot-spot JIT'ed code (~10% on average according to one article).

they do need much less RAM and startup time is _a lot_ lower though.

here it is: "Right now peak performance is a bit worse than HotSpot, but we don’t want to advertise that (and we want to fix it of course)."

http://www.graalvm.org/docs/reference-manual/aot-compilation...

Post reply on HN