11 ms·

Can anyone tell how performant this code is vs original C code? How much do we lose (if anything) by using Rust in comparison to C?

filipncs 11y ago
Note that this is an openGL renderer, not a software renderer implemented in Rust. Makes it hard to compare.
mkesper 11y ago
This is not a 1:1 conversion of game mechanics, see goals of the project.
- cristicbz 11y ago
  I am hoping it will eventually cover game mechanics, see "Goals (subject to change)". Pull requests welcome!
- deleted 11y ago
  [deleted]
fsiefken 11y ago
In general Rust is fast but slower then C: "Rust is safe indeed but, unfortunately, far from fast. By the moment of writing this article, it is comparable to Java, Go, and Haskell regarding performance" http://www.viva64.com/en/b/0324/ http://www.viva64.com/en/b/0324/
- pshc 11y ago
  Wow, the article you linked is being defensive about something.
  - MichaelGG 11y ago
    And since it was published, Rust is now in second place in that benchmark game graph: http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
    - llogiq 11y ago
      Yeah, but that's only because teXitoi's and Joshua Landau's improvements to many Rust benchmarks are still open on the tracker. And it's still using 1.3 (Ok, 1.4 only came out yesterday). Note that this is not meant as an indictment of the maintainer, who is indeed working very hard to keep the site usable, accurate and useful.
      - igouy 11y ago
        >>(Ok, 1.4 only came out yesterday).<< Using 1.4 since 3pm PDT yesterday.
- vardump 11y ago
  I think good support for SIMD will go a long way. C++ is also pretty slow on its own, but with SIMD intrinsics (or lucky autovectorization [1]) it can be speedy. We're talking typically about 1.5 - 10x speedup in performance sensitive code with SIMD vs plain C++. Highest speedup I've seen was about 40x in sorting code. SIMD is a sorting demon. That said, I want safety more than speed. Speed I can get by writing an unsafe extension in C/C++. Safety is very hard to achieve in C/C++. Getting it right is the first priority. That's why I see Rust being used instead of where traditionally C++ is the default. Or some other new language that can fill C++'s shoes. Rust does seem like the strongest candidate at this point. I'm confident Rust and Golang performance will improve as the projects get more mature. The generated code is full of optimization opportunities. [1]: Autovectorization optimizations by C++ compilers tend to be fragile, small changes will undo them. So far easier to use intrinsics than figure out the black magic for autovectorization optimizations.
  - kibwen 11y ago
    Note that SIMD support is currently in the Rust nightlies (as a result of Huon Wilson's summer internship at Mozilla), though I don't know what the timeline is for exposing that support in a stable release.
- EugeneOZ 11y ago
  Please don't quote this piece of shit. Seller of C++ tool trying to say "use C++ instead of Rust".
- yokohummer7 11y ago
  Please not this again. The article you mentioned is incorrect in many places, and was heavily criticized in various communities.[1][2] It doesn't qualify as a valid criticism. It is rather a badly written static analyzer promotion. Also, microbenchmarks are usually not very good at representing the real world characteristics. But then again, please look at the current version of the linked benchmark.[3] Rust now positions itself in the second place, thanks to the recent improvements given to the Rust programs used in the benchmarks. I believe Rust isn't as fast as highly optimized C, but I think it is safe to say that Rust is just as fast as C++, and both Rust and C++ are much faster than GC'ed languages such as Java, Haskell, and Go. Edit: I would even say that if Rust's performance is comparable to GC'ed languages, there's no point in using Rust in the first place. Rust is paying a lot of complexity to achieve memory safety without relying on garbage collection. [1] https://news.ycombinator.com/item?id=9531822 https://news.ycombinator.com/item?id=9531822 [2] https://www.reddit.com/r/cpp/comments/35pn6h/criticizing_the_rust_language_and_why_cc_will/cr6o9tz https://www.reddit.com/r/cpp/comments/35pn6h/criticizing_the... [3] http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
  - johncolanduoni 11y ago
    > Edit: I would even say that if Rust's performance is comparable to GC'ed languages, there's no point in using Rust in the first place. Rust is paying a lot of complexity to achieve memory safety without relying on garbage collection. Rust has a lot of nice safety features not related to memory management that I'd love to see even in a language with GC. On top of the obvious lack of data races, linear types and borrowing are great for ensuring other kinds of sanity like preventing you from mutating a collection while you iterate over it.
    - Gankro 11y ago
      Technically Rust doesn't have proper linear typing, only affine typing. Destructors give you "basically" linear typing, but there's ways to bypass destructors both explicitly and accidentally (though if memory safety isn't at stake, this isn't a worth worrying about IMO): https://doc.rust-lang.org/nomicon/leaking.html https://doc.rust-lang.org/nomicon/leaking.html
lispit 11y ago
Original game: An entire game, written mostly in C for a (comparatively) extremely primitive CPU with a similarly primitive compiler. Performs all rendering in software, with tightly optimized x86 assembly targeted towards said extremely out of date architecture, and was the absolute bleeding edge of what was possible when it was released. On top of that, DOS was the target, which meant that a fair part of the codebase is dedicated to what programmers today would think of as an operating system, from device drivers to interrupt handlers to memory managers. This: A level renderer with none of the game logic, written in a higher level language that, nonetheless, has access to a much, much more sophisticated compiler and target hardware than the original game had, that offloads most of the rendering to the GPU anyway, whose author was never once required to think about optimizing anything because any computer made in the last decade could render such scenes in its sleep a thousand times over without so much as a snore. I'm not at all trying to poo-poo the author here, but there is no meaningful comparison you can draw from this.
- iso8859-1 11y ago
  Do you think it would be possible to write the original game in mostly safe Rust with no performance hit?
  - markild 11y ago
    There would most definitely be a performance hit, but you would notice.
    - Dylan16807 11y ago
      Even if the new code made itself amenable to those nice vector units in modern CPUs?
  - lispit 11y ago
    No perceptible performance hit on a modern machine? Absolutely. I'm sure you can run 100 copies of Doom simultaneously in Javascript or whatever. No perceptible performance hit on a 486? Somehow, I don't think that the 486 is an especially important target for the LLVM or Rust developers (though such chips are used in embedded applications to this day). But the real reason that the comparison makes no sense is that the bulk of the processing time (but not the bulk of the code, mind you) is spent in those tightly optimized assembly loops. Either you keep it as such and it's not really much of a battle between C and Rust any more, or you rewrite the critical sections in Rust and you'd lose as hard or more as if you wrote them in C.
geowwy 11y ago
Not sure about this code, but in general rust seems to be in the ballpark of C and C++: http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
- slacka 11y ago
  Wow Rust 20%+ faster than gcc / C in k-nucleotide and fasta. Then again the Rust vs C++ makes me wonder if this benchmark is flawed. 4.4 vs 38 seconds for binary-trees. Somethings not right with some of those tests. Edit: Looks like an C++ optimization issue in that specific task. Broken down by task, C is at the top followed by Rust.[1] Rust is at or near the top in every category. Very impressive. [1] http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees http://benchmarksgame.alioth.debian.org/u64q/performance.php...
  - igouy 11y ago
    What you see is a couple of toy benchmark programs being "20%+ faster" than a couple of other toy benchmark programs, in a particular context [those language implementations, those command lines, that OS, that hardware…]. Remember, it depends how you write the programs!
- Veedrac 11y ago
  I wouldn't trust any of the benchmarks in the Benchmarks Game. I say this as someone who spent a fair while optimizing the Rust benchmarks to use all of the hacks the other languages use in some[1]. _Very_ few of the benchmarks are actually fair, and those that are normally don't matter. You're generally better off with random internet tests than the Benchmarks Game, since they at least don't have the kind of cheating-but-not-cheating that ruins the Benchmarks Game. That said, it's totally possible to do assembly-level tuning in Rust and, sans-SIMD, there's no real difficulty with getting Rust to go fast on these workflows. [1] https://alioth.debian.org/tracker/?func=browse&group_id=100815&atid=413122; https://alioth.debian.org/tracker/?func=browse&group_id=1008... See ones with "Joshua Landau" in title. All (but thread_ring, which is literally the silliest benchmark I've ever seen) beat C++ (sometimes by a lot). The disclaimer would be that none of my submissions have been submitted (or rejected) yet.
wiremine 11y ago
I had a follow up question: Are things at the point where you could reasonable write a modern 3D engine using Rust 1.0? [1] What would be the tradeoffs at this point vs. C++? [1] Ignoring all the tooling involved with art, music, etc.
- Tyr42 11y ago
  I think you should check out Arcaders.rs. There are still proposals for some sort of inheritance to be added, to make it easier to do the DOM, which might (or might not) be useful for an entity system. Also, you'd likely want to be using Rust 1.4. It just came out this week. http://jadpole.github.io/arcaders/arcaders-1-1/ http://jadpole.github.io/arcaders/arcaders-1-1/
- kibwen 11y ago
  The Rust ecosystem is still building up a lot of the libraries to make game programming practical. A lot of this is happening under the auspices of the "Piston" organization on Github: https://github.com/PistonDevelopers/ https://github.com/PistonDevelopers/ . Piston itself is sort-of-a-game-engine, sort-of-a-collection-of-modular-game-related-libraries. Meanwhile, Rust also has the Glium library for OpenGL programming, which is apparently so good that it makes OpenGL programmers froth at the mouth (I've never done OpenGL programming myself, but the praise is universal among all my graphics-programming friends).
- CyberDildonics 11y ago
  Because Rust uses LLVM to optimize the gap between C++ should be small enough that architecting for memory allocation and cache locality should FAR outweigh the difference in language implementations. If you look at things like Ogre and Box2D, they can likely be sped up by a factor of 10x in either language. (not total fps in ogre, just the engine part).
CyberDildonics 11y ago
It is a re-implementation, not a port so the comparison would be far from 1:1. The original C implementation also had the rendering loop done in pure asm.

filipncs 11y ago

Note that this is an openGL renderer, not a software renderer implemented in Rust. Makes it hard to compare.

mkesper 11y ago

This is not a 1:1 conversion of game mechanics, see goals of the project.

cristicbz 11y ago
I am hoping it will eventually cover game mechanics, see "Goals (subject to change)". Pull requests welcome!
deleted 11y ago
[deleted]

fsiefken 11y ago

In general Rust is fast but slower then C: "Rust is safe indeed but, unfortunately, far from fast. By the moment of writing this article, it is comparable to Java, Go, and Haskell regarding performance" http://www.viva64.com/en/b/0324/ http://www.viva64.com/en/b/0324/

pshc 11y ago
Wow, the article you linked is being defensive about something.
- MichaelGG 11y ago
  And since it was published, Rust is now in second place in that benchmark game graph: http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
  - llogiq 11y ago
    Yeah, but that's only because teXitoi's and Joshua Landau's improvements to many Rust benchmarks are still open on the tracker. And it's still using 1.3 (Ok, 1.4 only came out yesterday). Note that this is not meant as an indictment of the maintainer, who is indeed working very hard to keep the site usable, accurate and useful.
    - igouy 11y ago
      >>(Ok, 1.4 only came out yesterday).<< Using 1.4 since 3pm PDT yesterday.
vardump 11y ago
I think good support for SIMD will go a long way. C++ is also pretty slow on its own, but with SIMD intrinsics (or lucky autovectorization [1]) it can be speedy. We're talking typically about 1.5 - 10x speedup in performance sensitive code with SIMD vs plain C++. Highest speedup I've seen was about 40x in sorting code. SIMD is a sorting demon. That said, I want safety more than speed. Speed I can get by writing an unsafe extension in C/C++. Safety is very hard to achieve in C/C++. Getting it right is the first priority. That's why I see Rust being used instead of where traditionally C++ is the default. Or some other new language that can fill C++'s shoes. Rust does seem like the strongest candidate at this point. I'm confident Rust and Golang performance will improve as the projects get more mature. The generated code is full of optimization opportunities. [1]: Autovectorization optimizations by C++ compilers tend to be fragile, small changes will undo them. So far easier to use intrinsics than figure out the black magic for autovectorization optimizations.
- kibwen 11y ago
  Note that SIMD support is currently in the Rust nightlies (as a result of Huon Wilson's summer internship at Mozilla), though I don't know what the timeline is for exposing that support in a stable release.
EugeneOZ 11y ago
Please don't quote this piece of shit. Seller of C++ tool trying to say "use C++ instead of Rust".
yokohummer7 11y ago
Please not this again. The article you mentioned is incorrect in many places, and was heavily criticized in various communities.[1][2] It doesn't qualify as a valid criticism. It is rather a badly written static analyzer promotion. Also, microbenchmarks are usually not very good at representing the real world characteristics. But then again, please look at the current version of the linked benchmark.[3] Rust now positions itself in the second place, thanks to the recent improvements given to the Rust programs used in the benchmarks. I believe Rust isn't as fast as highly optimized C, but I think it is safe to say that Rust is just as fast as C++, and both Rust and C++ are much faster than GC'ed languages such as Java, Haskell, and Go. Edit: I would even say that if Rust's performance is comparable to GC'ed languages, there's no point in using Rust in the first place. Rust is paying a lot of complexity to achieve memory safety without relying on garbage collection. [1] https://news.ycombinator.com/item?id=9531822 https://news.ycombinator.com/item?id=9531822 [2] https://www.reddit.com/r/cpp/comments/35pn6h/criticizing_the_rust_language_and_why_cc_will/cr6o9tz https://www.reddit.com/r/cpp/comments/35pn6h/criticizing_the... [3] http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
- johncolanduoni 11y ago
  > Edit: I would even say that if Rust's performance is comparable to GC'ed languages, there's no point in using Rust in the first place. Rust is paying a lot of complexity to achieve memory safety without relying on garbage collection. Rust has a lot of nice safety features not related to memory management that I'd love to see even in a language with GC. On top of the obvious lack of data races, linear types and borrowing are great for ensuring other kinds of sanity like preventing you from mutating a collection while you iterate over it.
  - Gankro 11y ago
    Technically Rust doesn't have proper linear typing, only affine typing. Destructors give you "basically" linear typing, but there's ways to bypass destructors both explicitly and accidentally (though if memory safety isn't at stake, this isn't a worth worrying about IMO): https://doc.rust-lang.org/nomicon/leaking.html https://doc.rust-lang.org/nomicon/leaking.html

lispit 11y ago

Original game: An entire game, written mostly in C for a (comparatively) extremely primitive CPU with a similarly primitive compiler. Performs all rendering in software, with tightly optimized x86 assembly targeted towards said extremely out of date architecture, and was the absolute bleeding edge of what was possible when it was released. On top of that, DOS was the target, which meant that a fair part of the codebase is dedicated to what programmers today would think of as an operating system, from device drivers to interrupt handlers to memory managers. This: A level renderer with none of the game logic, written in a higher level language that, nonetheless, has access to a much, much more sophisticated compiler and target hardware than the original game had, that offloads most of the rendering to the GPU anyway, whose author was never once required to think about optimizing anything because any computer made in the last decade could render such scenes in its sleep a thousand times over without so much as a snore. I'm not at all trying to poo-poo the author here, but there is no meaningful comparison you can draw from this.

iso8859-1 11y ago
Do you think it would be possible to write the original game in mostly safe Rust with no performance hit?
- markild 11y ago
  There would most definitely be a performance hit, but you would notice.
  - Dylan16807 11y ago
    Even if the new code made itself amenable to those nice vector units in modern CPUs?
- lispit 11y ago
  No perceptible performance hit on a modern machine? Absolutely. I'm sure you can run 100 copies of Doom simultaneously in Javascript or whatever. No perceptible performance hit on a 486? Somehow, I don't think that the 486 is an especially important target for the LLVM or Rust developers (though such chips are used in embedded applications to this day). But the real reason that the comparison makes no sense is that the bulk of the processing time (but not the bulk of the code, mind you) is spent in those tightly optimized assembly loops. Either you keep it as such and it's not really much of a battle between C and Rust any more, or you rewrite the critical sections in Rust and you'd lose as hard or more as if you wrote them in C.

geowwy 11y ago

Not sure about this code, but in general rust seems to be in the ballpark of C and C++: http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64q/which-programs-...

slacka 11y ago
Wow Rust 20%+ faster than gcc / C in k-nucleotide and fasta. Then again the Rust vs C++ makes me wonder if this benchmark is flawed. 4.4 vs 38 seconds for binary-trees. Somethings not right with some of those tests. Edit: Looks like an C++ optimization issue in that specific task. Broken down by task, C is at the top followed by Rust.[1] Rust is at or near the top in every category. Very impressive. [1] http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees http://benchmarksgame.alioth.debian.org/u64q/performance.php...
- igouy 11y ago
  What you see is a couple of toy benchmark programs being "20%+ faster" than a couple of other toy benchmark programs, in a particular context [those language implementations, those command lines, that OS, that hardware…]. Remember, it depends how you write the programs!
Veedrac 11y ago
I wouldn't trust any of the benchmarks in the Benchmarks Game. I say this as someone who spent a fair while optimizing the Rust benchmarks to use all of the hacks the other languages use in some[1]. _Very_ few of the benchmarks are actually fair, and those that are normally don't matter. You're generally better off with random internet tests than the Benchmarks Game, since they at least don't have the kind of cheating-but-not-cheating that ruins the Benchmarks Game. That said, it's totally possible to do assembly-level tuning in Rust and, sans-SIMD, there's no real difficulty with getting Rust to go fast on these workflows. [1] https://alioth.debian.org/tracker/?func=browse&group_id=100815&atid=413122; https://alioth.debian.org/tracker/?func=browse&group_id=1008... See ones with "Joshua Landau" in title. All (but thread_ring, which is literally the silliest benchmark I've ever seen) beat C++ (sometimes by a lot). The disclaimer would be that none of my submissions have been submitted (or rejected) yet.

wiremine 11y ago

I had a follow up question: Are things at the point where you could reasonable write a modern 3D engine using Rust 1.0? [1] What would be the tradeoffs at this point vs. C++? [1] Ignoring all the tooling involved with art, music, etc.

Tyr42 11y ago
I think you should check out Arcaders.rs. There are still proposals for some sort of inheritance to be added, to make it easier to do the DOM, which might (or might not) be useful for an entity system. Also, you'd likely want to be using Rust 1.4. It just came out this week. http://jadpole.github.io/arcaders/arcaders-1-1/ http://jadpole.github.io/arcaders/arcaders-1-1/
kibwen 11y ago
The Rust ecosystem is still building up a lot of the libraries to make game programming practical. A lot of this is happening under the auspices of the "Piston" organization on Github: https://github.com/PistonDevelopers/ https://github.com/PistonDevelopers/ . Piston itself is sort-of-a-game-engine, sort-of-a-collection-of-modular-game-related-libraries. Meanwhile, Rust also has the Glium library for OpenGL programming, which is apparently so good that it makes OpenGL programmers froth at the mouth (I've never done OpenGL programming myself, but the praise is universal among all my graphics-programming friends).
CyberDildonics 11y ago
Because Rust uses LLVM to optimize the gap between C++ should be small enough that architecting for memory allocation and cache locality should FAR outweigh the difference in language implementations. If you look at things like Ogre and Box2D, they can likely be sped up by a factor of 10x in either language. (not total fps in ogre, just the engine part).

CyberDildonics 11y ago

It is a re-implementation, not a port so the comparison would be far from 1:1. The original C implementation also had the rendering loop done in pure asm.