Hacker News new | ask | show | jobs
by adrian_b 1664 days ago
The fact that the indirect jump that returns when an error is encountered is not predicted, is never worse than when testing an error code returned by the function, because that conditional jump is also always mispredicted.

The method used by modern languages requires both an indirect jump for return, hopefully predicted, and a mispredicted conditional jump. Moreover, if the invoking function is executed once more, but the next time there is no error, the conditional jump that tests the error code may be mispredicted once more.

Using multiple return labels requires only a single mispredicted unconditional jump and it also omits a bunch of redundant instructions for generating an error code and testing it.

For functions that may encounter multiple types of errors, the economy is much larger because testing the returned error code would have needed either multiple conditional branches or an indirect indexed jump for a switch/case structure.

1 comments

I think that right now, there is sufficient motivation to implement enough of this to be able to try it out, and then see how it actually behaves in practice.

But Rust works on a really wide range of kinds of processors - CPUs, GPUs, FPGAs - and hardware architectures (dozen CPU architectures, dozen GPU architectures, etc.), and nobody has shown that this is a net win for all of them.

Figuring out for which, if any, this is a net win, is something that will have to be demonstrated.

When you say FPGA, do you mean running on soft cores or do you mean high level synthesis from Rust directly?
Running on soft cores.