4 ms·

That also holds for Java ;). The difference is in the targeted execution model.

by choeger 8y ago

Scarbutt 8y ago
Java is very fast too ;)
- sanxiyn 8y ago
  Yup, 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 ago
    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.
    - nazka 8y ago
      Nice post. I will be really curious to see the same microservice done with Go and compare all of them.
      - nevi-me 8y ago
        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.
        kaixi 8y ago
        Please do. I'm interested as well.
diroussel 8y ago
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.
- pjmlp 8y ago
  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.
  - nadioca 8y ago
    How does it compare against c/c++ in terms of performance ?
    - pjmlp 8y ago
      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.
    - stefs 8y ago
      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/ http://www.graalvm.org/docs/reference-manual/aot-compilation...
pjmlp 8y ago
Not 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.

That also holds for Java ;). The difference is in the targeted execution model.

Scarbutt 8y ago

Java is very fast too ;)

sanxiyn 8y ago
Yup, 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 ago
  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.
  - nazka 8y ago
    Nice post. I will be really curious to see the same microservice done with Go and compare all of them.
    - nevi-me 8y ago
      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.
      - kaixi 8y ago
        Please do. I'm interested as well.

diroussel 8y ago

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.

pjmlp 8y ago
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.
- nadioca 8y ago
  How does it compare against c/c++ in terms of performance ?
  - pjmlp 8y ago
    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.
  - stefs 8y ago
    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/ http://www.graalvm.org/docs/reference-manual/aot-compilation...

pjmlp 8y ago

Not 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.