6 ms·
Rust is Not so Hairy
- nevi-me 8y agoA 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.
- jokoon 8y agoGood performance is not surprising, it's a statically compiled language.
- choeger 8y agoThat also holds for Java ;). The difference is in the targeted execution model.
- Scarbutt 8y agoJava is very fast too ;)
- sanxiyn 8y agoYup, Java is fast, but OP shared that Rust used 7 MB to do the same thing for which Java used 240 MB.
- nevi-me 8y agoFrom 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.
- nazka 8y agoNice post. I will be really curious to see the same microservice done with Go and compare all of them.
- diroussel 8y agoJava 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.
- pjmlp 8y agoIf 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.
- nadioca 8y agoHow does it compare against c/c++ in terms of performance ?
- pjmlp 8y agoOf 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.
- stefs 8y agothe 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/ http://www.graalvm.org/docs/reference-manual/aot-compilation...
- pjmlp 8y agoNot really, Java always had AOT compilers to native code, they just happened to be commercial and we all know how modern developers love to pay for their tools.
- littlestymaar 8y agoBeing “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.
- skybrian 8y agoI 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.
- imtringued 8y agoThe 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.
- pjmlp 8y ago> 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.
- carlmr 8y agoOnce 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.
- nevi-me 8y agoDo 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.
- carlmr 8y agoBasically 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.
- majewsky 8y ago> 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).
- nevi-me 8y agoIt 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.
- blackrock 8y ago// Mutable pointer to the field. // If field is not initialized, it is initialized with default value first. pub fn mut_message(&mut self) -> &mut ::std::string::String { &mut self.message } ========= Geez, this is ugly. And here's another.. ========= // Take field pub fn take_message(&mut self) -> ::std::string::String { ::std::mem::replace(&mut self.message, ::std::string::String::new()) }