[HN Gopher] Translating Quake 3 into Rust (2020)
___________________________________________________________________
Translating Quake 3 into Rust (2020)
Author : lukastyrychtr
Score : 112 points
Date : 2021-06-12 17:07 UTC (5 hours ago)
(HTM) web link (immunant.com)
(TXT) w3m dump (immunant.com)
| [deleted]
| habibur wrote:
| Need some benchmark numbers after that.
|
| Rust compiled binary FPS vs C code FPS.
| gostsamo wrote:
| previous discussion:
|
| https://news.ycombinator.com/item?id=21979555
| fsiefken wrote:
| So, is quake3 more performant with the rust version? not that it
| really matters in modern hardware, but I'm curious if Quake3 rust
| would run faster on my 486.
| Synaesthesia wrote:
| Quake 1 wouldn't even run on a 486, and Q3 needed a GPU, one of
| the first games to have that requirement.
| fsiefken wrote:
| Quake1 ran on my 486 for sure, I think I also tried Q3. I
| think I was running either slackware or mandriva. All games
| required a GPU, so you probably mean DirectX or OpenGL
| acceleration.
|
| Yes, so given the existence of OpenGL acceleration on chip
| would this rust version be significantly more performant than
| the c++ version?
| [deleted]
| SV_BubbleTime wrote:
| > Pointers to Arrays
|
| >In a few places, the original source code contains expressions
| that point one past the last element of an array. Here is a
| simplified example of the C code: int
| array[1024]; int *p; if (p >=
| &array[1024]) { }
|
| >The C standard (see e.g. C11, Section 6.5.6) allows pointers to
| an element one past the end of the array.
|
| Wait? Why?
|
| I get that char strings in C are null terminated and that might
| seem like an off by 1 issue if you aren't paying attention, you
| still size your string one larger than your string.
|
| What is this all about?
| kimixa wrote:
| It's so you can do exactly what's being done here - see if you
| have reached the end of the array by comparing the current
| position pointer.
|
| Lots of iterator designs have a special "end" iterator you can
| compare against but not deference or access - this is just the
| same for C arrays.
|
| The C standard here allows pointers to elements one past the
| array, but it's still busted if you try to dereference it.
| SV_BubbleTime wrote:
| Makes sense. I got what they were doing but in my head
| combined the C statement of addressing and
| accessing/dereferencing.
| pix64 wrote:
| You can point to the element one pass, but you cannot
| dereference the pointer.
| SV_BubbleTime wrote:
| Ah, I get it now.
|
| And it's interesting to me that Rust doesn't allow that
| considering it's not accessing memory (yet, and that's the
| whole point I'm sure.
| Diggsey wrote:
| Pointers in Rust behave the same way. The problem is that
| the "array index" operator in Rust returns a _reference_ to
| the indexed element, not a pointer, and references must be
| safely dereferenceable.
| pwdisswordfish8 wrote:
| #define COUNT(array) (sizeof(array) / sizeof((array)[0]))
| int array[1024]; for (int *p = array; p < array +
| COUNT(array); ++p) { // ... }
|
| For the loop to be well-behaved, such pointer formation must be
| well-defined.
| steveklabnik wrote:
| It is _very_ confusing to me that you 've been downvoted in
| this thread. Anyone who did so want to explain why?
| fallingfrog wrote:
| I second that. Why punish someone for asking a pretty
| understandable question?
| bertr4nd wrote:
| I didn't downvote (I can't, and I wouldn't have anyways) but
| I've often see the "Wait? Why?" (Or "wait, what?") construct
| carries a connotation of "Why are you doing this insane bad
| thing?" which people sometimes react negatively to.
| steveklabnik wrote:
| Ah, that would make sense. I wouldn't have thought of it
| that way. Thanks.
| SV_BubbleTime wrote:
| Yea, maybe it's that, but every other post I've made is
| also offended someone deeply or so it would seem :)
| defaultname wrote:
| C arrays are nothing more than convenient pointer math.
| array[1024] = &array + sizeof(element) * index (in that case
| 1024). And while there is some weird post-facto "one past the
| end" bit in the standard (added long after Quake 3 was made),
| in any modern compiler you can happily get pointers for illegal
| indexes. If you have a literally sized array and a literal
| offset it could warn (e.g. Warray-bounds), but for the vast
| majority of cases it won't flag at all. Nor would this cause
| any runtime issues. Because it's just math.
|
| And the truth is that without runtime memory protection you can
| dereference those illegal positions.
| oscargrouch wrote:
| Reading at the transpiled code, theres something that make me a
| little worried if this becomes a trend. The lost information in
| the process. I guess if there's an AI in the middle, capturing
| the logical context and later helping into the translation
| process.
|
| In that way the power of the source code to teach us will still
| be there.
|
| I understand if some tool that is in C and need a boost in
| security might use this, but giving the output code is
| intractable, they would still have to code in C, so this kind of
| defeat the some of the goals of writing code in a more secure
| environment.
|
| Its important to understand that security is just one of the axis
| of a whole that have much more things to consider.
|
| Having said that, maybe there will be a good use for source code
| in C that needs a safety boost right away in critical places, or
| use something like this to spot dark corners and fix the code
| back in C.
|
| Also, great hacking points to whoever did this, as this is fun
| just because is hacking at its best.
| brundolf wrote:
| You don't get much of a safety boost right away with the auto-
| translation, because a lot (all?) of it will start out wrapped
| in unsafe blocks. The idea is to use it as a jumping-off point
| from which you can gradually migrate more and more code into
| safety
| oscargrouch wrote:
| That makes sense. But i wonder if two teams creating a port,
| one straight from the C code and the other with the
| translation output..
|
| Which one would end first and with the best version..
|
| (Not sure if doing this from the transpiled code is the best
| option, giving you will miss a lot of otherwise informative
| context in the original source)
___________________________________________________________________
(page generated 2021-06-12 23:02 UTC)