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

11–20 of 36 posts

Re: Rust is Not so Hairy

#11

Post by nadioca »

pjmlp wrote: post #10
diroussel wrote: post #7

Earlier quoted context omitted.

Java is not statically compiles to machine code. It’s statically compiles to byte code which is hen interpreted or dynamically compiles to machine code. So to way java is statically compiles is not quite correct in my opinion.

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 ?

Re: Rust is Not so Hairy

#12

Post by littlestymaar »

jokoon wrote: post #4

Good performance is not surprising, it's a statically compiled language.

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 statically-compiled language, its compiler is way less aggressive with optimization because the Go compiler developers wants to keep the compile-time low (which is probably a good idea in their niche) and because it has been much less of a focus than for LLVM or Gcc. As a result, Go is slower than C/C++/Rust by almost an order of magnitude, despite being statically compiled.

Another example: if you compile C code with `-O0` optimization level, it will still be statically compiled, but it will be way slower than most JIT-ed languages.

Re: Rust is Not so Hairy

#13

Post by nevi-me »

sanxiyn wrote: post #8
Scarbutt wrote: post #6

Earlier quoted context omitted.

Java is very fast too ;)

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 more on the same machine; I'm happy.

Re: Rust is Not so Hairy

#14

Post by pjmlp »

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 ?

Of course it is a bit slower, as Java does not take advantage of UB nor disabling security checks for the ultimate performance.

And depending on the use case there is always the issue of value vs reference types.

But it is good enough for most use cases of typical desktop software, to the point of Oracle's long term roadmap is to rewrite the remaining C++ parts of OpenJDK in Java (Project Metropolis), using a subset they are designing called System Java.

Also can check Android flagship devices (better for performance comparison), since Android 5.0, Java is also AOT compiled to native code. Although Android 7 changes it to a mix of interpreter written in Assembly, JIT and AOT with PGO. And Android P will introduce sharing of PGO metadata across devices via Play Store.

Re: Rust is Not so Hairy

#15

Post by skybrian »

littlestymaar wrote: post #12
jokoon wrote: post #4

Good performance is not surprising, it's a statically compiled language.

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…

I agree that the Go compiler doesn't optimize as aggressively, but it's not that simple. I've heard of a rewrite of some legacy code from C++ to Go making the code go faster.

A rewrite often includes a redesign, which can make more of a difference than compiler optimizations.

If they ported back to C++ again, it would probably be faster still. But there are also maintenance concerns to think about.

Re: Rust is Not so Hairy

#16

Post by imtringued »

littlestymaar wrote: post #12
jokoon wrote: post #4

Good performance is not surprising, it's a statically compiled language.

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…

The reason why C or Rust are fast is primarily the increase data locality. In java, js or python everything is a pointer. Fetching random parts of memory is expensive therefore if you want to keep the CPU fed with data you need continguous data structures. In theory nothing other than data locality stops JS from being faster than C and the proof is webassemby which gets 50% of the performance of native code which is really impressive considering that webassembly runs inside a sandbox that prevents glaring security issues like bufferoverflows on the stack from rewriting the return address.

Re: Rust is Not so Hairy

#17

Post by carlmr »

jokoon wrote: post #4

Good performance is not surprising, it's a statically compiled language.

Once you understand the borrow checker and how you can do a lot of zero copy string processing after you read in a file you will see it's a bit more than being statically compiled.

Re: Rust is Not so Hairy

#18

Post by nevi-me »

carlmr wrote: post #17
jokoon wrote: post #4

Good performance is not surprising, it's a statically compiled language.

Once you understand the borrow checker and how you can do a lot of zero copy string processing after you read in a file you will see it's a bit more than being statically compiled.

Do you have a brief example, or is it the normal "I am a str".to_string()? I still have a long way to go with learning how Rust works.

I've heard about zero-copy in C and C++, but don't have an idea of how it's implemented in practise.

Re: Rust is Not so Hairy

#19

Post by carlmr »

nevi-me wrote: post #18
carlmr wrote: post #17

Earlier quoted context omitted.

Once you understand the borrow checker and how you can do a lot of zero copy string processing after you read in a file you will see it's a bit more than being statically compiled.

Do you have a brief example, or is it the normal "I am a str".to_string()? I still have a long way to go with learning how Rust works. I've heard about zero-copy in C and C++, but don't have an idea of how it's implemented in practise.

Basically what you can do is, e.g. Reading in a file. Now you have a string containing all your file.

When you then write a parser you can write it so that it uses string slices pointing into your file buffer whenever it references any text from your file, instead of creating new strings.

As long as you don't need to modify anything you don't need to create any copies and the borrow checking compiler will ensure that you don't invalidate any part of your buffer.

For a lot of parsers string allocation is a big part of runtime performance.

Re: Rust is Not so Hairy

#20

Post by pjmlp »

littlestymaar wrote: post #12
jokoon wrote: post #4

Good performance is not surprising, it's a statically compiled language.

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.

Post reply on HN