News for hackers. Stuff that matters.
Re:Translating Quake 3 into Rust by masklinn on Tuesday January 07, 2020 @10:36AM (#21980902)
> What is the realistic best-case scenario?

Finding latent logic and memory errors, gaining greater confidence, security and velocity.

> Has anyone demonstrated that well-written Rust code should run faster than C

Should? No. Can? Yes. See Brian Cantrill’s http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa... or Cliff Biffle’s http://cliffle.com/p/dangerust/

Re:Translating Quake 3 into Rust by vintermann on Tuesday January 07, 2020 @12:11PM (#21981955)
There are some "shoulds" related to aliasing I believe. Things the compiler can assume when compiling a rust program that it can't when compiling C, which should in theory let it generate more efficient code.

But last I heard Rust wasn't taking advantage of this due to issues with LLVM. The same benefits should also be achievable in C with pragmas.

Re:Translating Quake 3 into Rust by masklinn on Tuesday January 07, 2020 @02:32PM (#21983780)
> There are some "shoulds" related to aliasing I believe.

c2rust has to be careful not to "restrict" pointers which can in fact alias.

> But last I heard Rust wasn't taking advantage of this due to issues with LLVM.

That's correct: https://github.com/rust-lang/rust/issues/54878

> The same benefits should also be achievable in C with pragmas.

I don't know that any compiler provides a noalias-all pragma. I don't know that it would be very sane either since C very much defines pointers as aliasing by default. Plus you wouldn't have any way to revert this behaviour and mark pointers as aliasing.

Re:Translating Quake 3 into Rust by jashmatthews on Tuesday January 07, 2020 @06:06PM (#21986224)
> C very much defines pointers as aliasing by default.

This is actually a huge issue for the CRuby JIT which generates C from the VM bytecode. Alias analysis on the generated C code, which is full of indirection, is basically useless and severely restricts the possible optimizations.