6 ms·

Something I always wonder for games not made with C++: how is the performance?

• VMG 12y ago
  Though in this case it makes sense to compare it to the "reference implementation" in Java. Regular Minecraft has noticeable GC pauses in my opinion.
  • kibwen 12y ago
    Hematite doesn't implement anything near to the full game, so it wouldn't be a fair comparison. It's mostly just a world visualizer, sort of like Overseer is for Dwarf Fortress ( http://www.bay12forums.com/smf/index.php?topic=63484 http://www.bay12forums.com/smf/index.php?topic=63484 ). And although it would probably make a good jumping-off point for anyone who wanted to develop a Minecraft clone, the original goal of Hematite was only to serve as a proof-of-concept of rendering 3D graphics in Rust.
  • pkolaczk 12y ago
    Are you sure they are caused by GC? I'm asking because GC is an easy "culprit" and when a Java app pauses / jitters, many people immediately blame it on GC without any hard evidence. While in fact pauses / unresponsiveness can be caused by many other reasons, not specific to JVM (e.g. improper thread locking, improper use of dynamic data structures, doing hard work on the GUI thread, etc.). Actually, a well coded game should not use dynamic memory allocation in the game loop, neither in Java nor in C++.
    • Havvy 12y ago
      I've seen Minecraft generate 400Mb/min worth of garbage and then GC with a noticable stutter. The most egregious stutter though is when Minecraft generates new chunks. Minecraft is not a well-coded game. ;)
• Manishearth 12y ago
  Note: Rust is designed to be as efficient as C++. Well, sort of, since we don't have all of the optimizations yet (we use llvm so we get most of them for free) But Minecraft itself is in Java. And it does get pretty slow even with low settings as compared to other games on high settings.
  • mrob 12y ago
    Rust uses bounds checking in safe code, and despite idiomatic Rust allowing many bounds checks to be optimized out (eg. iterators instead of C style for loops), bounds checks are not free. It's possible that things like stricter aliasing rules in Rust will allow more optimizations and make up the speed difference, but the design of Rust does not guarantee the possibility of matching C++ performance unless you use unsafe code.
    • steveklabnik 12y ago
      > Rust does not guarantee the possibility of matching C++ performance unless you use unsafe code. As with any performance question, this is hard to actually say in general. In the Benchmarks game(1), there are several benchmarks where Rust has no unsafe code and is still faster than C. 1: personal note: ugh, all usual caveats apply, etc.
      • igouy 12y ago
        If you think there's something wrong about the benchmarks game then don't point to the benchmarks game as evidence for what you wish to be true.
    • saidajigumi 12y ago
      At some point the performance margin grows so close that it's irrelevant to almost any application. IMO, it's already there for a broad swath of application classes. For those inner-most-loop, optimizer-has-failed-me cases, Rust can still fall back on unsafe code. I'll note that this kind of skepticism has been going on since John Backus[1] was heckled over using (ahem, "wasting") then-precious CPU time on compiling code using the first versions of FORTRAN. His detractors (and everyone else) quickly learned the value of conserving programmer time vs. CPU time. [1] https://en.wikipedia.org/wiki/John_Backus https://en.wikipedia.org/wiki/John_Backus