4 ms·

Recently ran a benchmark against Rust and Java for a particular aspect of our code. The Rust completed in less time, using one thread. Java required twice the t

Recently ran a benchmark against Rust and Java for a particular aspect of our code. The Rust completed in less time, using one thread. Java required twice the time, twice the memory, and thirty five threads. Even if your GC isn't pausing, it's still using as many CPUs as it can to trash your d-cache looking for objects to GC.

pjmlp 5y ago
Because you were comparing Apples to Oranges. Now try that against D, any .NET language, Nim, Swift, Go, or any other GC language that supports value types and unsafe programming.
- wsc981 5y ago
  Swift is technically not a language with GC I believe. It's probably using reference counting like Objective-C before.
  - pjmlp 5y ago
    Reference counting is a GC algorithm, despite urban knowledge that describes it as otherwise. Chapter 5 on the "The Garbage Collection Handbook", https://gchandbook.org/contents.html https://gchandbook.org/contents.html Or if you prefer chapter 2 on "Uniprocessor Garbage Collection Techniques" https://www.cs.cmu.edu/~fp/courses/15411-f08/misc/wilson94-gc.pdf https://www.cs.cmu.edu/~fp/courses/15411-f08/misc/wilson94-g... Plenty of SIGPLAN papers about the subject. Despite all marketing talk, the real reason why Swift went with ARC was easier interoperability with Objective-C, otherwise Apple would need to build something like .NET's RCW/CCW for COM interop on Windows, which follows the same concept as Cocoa's retain/release calls.
bzzzt 5y ago
The only thing your benchmark proves is your Java could was not as optimized as well as your Rust code. Java has overhead, but certainly not two orders of magnitude.
- lowbloodsugar 5y ago
  Our use case is definitely a pathologically bad problem for Java's GC. Nevertheless, it is a real use case, and CPU and GC are the primary impacts to our service.
  - bzzzt 5y ago
    You mean you're actually seeing 90% GC overhead and are not looking to improve on that? (like by tuning the GC or changing your implementation). GC impact on normal behaving applications should be less than a few percent, so you're not comparing Rust and Java, but Rust and badly written/tuned Java - which doesn't say anything about the maximum attainable performance.
Johanx64 5y ago
Rust takes an absolute eternity to compile code. On that count alone I would never-ever consider it in hobby/games project of any sort. It doesn't matter what features a programming language has, if it takes seconds if not minutes to compile even relatively small projects (less than 50-100k LoC).
- akavel 5y ago
  Isn't compilation time in a roughly similar ballpark for C++? Which is kinda... "quite often" used in games projects? Not sure how much in hobby ones though, if that's what is being discussed here, but I'm somewhat confused (hobby/games sounds like speaking about an either-or alternative?)
  - pjmlp 5y ago
    Kind of, C++ profits that the ecosystem embraces binary libraries, so usually you only have to care about your own code. Then if you are using modern C++ tooling like Visual Studio, you can make use of hot code reload. Here are examples in Visual Studio, and Unreal. https://www.youtube.com/watch?v=x_gr6DNrJuM https://www.youtube.com/watch?v=x_gr6DNrJuM https://www.youtube.com/watch?v=XN1c1V9wtCk https://www.youtube.com/watch?v=XN1c1V9wtCk
- 3836293648 5y ago
  Why are you doing a clean build? You can't complain about the difference against binary dependencies if you're manually flushing the cache of built dependencies. And if you're not doing that, you're either wrong, or have a terrible project structure (comparable to including literally every header in every source file in C++)
- lowbloodsugar 5y ago
  That is genuinely one of our dilemmas. The product makes enough to spend an extra 20x on machines (and it scales horizontally). So does the impact to developer productivity of Rust offset the 20x cost savings? New features mean new $$$, and more than enough to offset the extra runtime cost of Java. Personally, I'm now doing hobby projects in Rust because it just feels right. But I've done entire systems in assembly, so I am a bit of a control freak. YMMV.

pjmlp 5y ago

Because you were comparing Apples to Oranges. Now try that against D, any .NET language, Nim, Swift, Go, or any other GC language that supports value types and unsafe programming.

wsc981 5y ago
Swift is technically not a language with GC I believe. It's probably using reference counting like Objective-C before.
- pjmlp 5y ago
  Reference counting is a GC algorithm, despite urban knowledge that describes it as otherwise. Chapter 5 on the "The Garbage Collection Handbook", https://gchandbook.org/contents.html https://gchandbook.org/contents.html Or if you prefer chapter 2 on "Uniprocessor Garbage Collection Techniques" https://www.cs.cmu.edu/~fp/courses/15411-f08/misc/wilson94-gc.pdf https://www.cs.cmu.edu/~fp/courses/15411-f08/misc/wilson94-g... Plenty of SIGPLAN papers about the subject. Despite all marketing talk, the real reason why Swift went with ARC was easier interoperability with Objective-C, otherwise Apple would need to build something like .NET's RCW/CCW for COM interop on Windows, which follows the same concept as Cocoa's retain/release calls.

bzzzt 5y ago

The only thing your benchmark proves is your Java could was not as optimized as well as your Rust code. Java has overhead, but certainly not two orders of magnitude.

lowbloodsugar 5y ago
Our use case is definitely a pathologically bad problem for Java's GC. Nevertheless, it is a real use case, and CPU and GC are the primary impacts to our service.
- bzzzt 5y ago
  You mean you're actually seeing 90% GC overhead and are not looking to improve on that? (like by tuning the GC or changing your implementation). GC impact on normal behaving applications should be less than a few percent, so you're not comparing Rust and Java, but Rust and badly written/tuned Java - which doesn't say anything about the maximum attainable performance.

Johanx64 5y ago

Rust takes an absolute eternity to compile code. On that count alone I would never-ever consider it in hobby/games project of any sort. It doesn't matter what features a programming language has, if it takes seconds if not minutes to compile even relatively small projects (less than 50-100k LoC).

akavel 5y ago
Isn't compilation time in a roughly similar ballpark for C++? Which is kinda... "quite often" used in games projects? Not sure how much in hobby ones though, if that's what is being discussed here, but I'm somewhat confused (hobby/games sounds like speaking about an either-or alternative?)
- pjmlp 5y ago
  Kind of, C++ profits that the ecosystem embraces binary libraries, so usually you only have to care about your own code. Then if you are using modern C++ tooling like Visual Studio, you can make use of hot code reload. Here are examples in Visual Studio, and Unreal. https://www.youtube.com/watch?v=x_gr6DNrJuM https://www.youtube.com/watch?v=x_gr6DNrJuM https://www.youtube.com/watch?v=XN1c1V9wtCk https://www.youtube.com/watch?v=XN1c1V9wtCk
3836293648 5y ago
Why are you doing a clean build? You can't complain about the difference against binary dependencies if you're manually flushing the cache of built dependencies. And if you're not doing that, you're either wrong, or have a terrible project structure (comparable to including literally every header in every source file in C++)
lowbloodsugar 5y ago
That is genuinely one of our dilemmas. The product makes enough to spend an extra 20x on machines (and it scales horizontally). So does the impact to developer productivity of Rust offset the 20x cost savings? New features mean new $$$, and more than enough to offset the extra runtime cost of Java. Personally, I'm now doing hobby projects in Rust because it just feels right. But I've done entire systems in assembly, so I am a bit of a control freak. YMMV.