Hacker News Reader

Comment by surrealize | Hacker News Reader

One of the slides shows a benchmark where Rust beats GCC; it would be really nice to see the code.

In what? Compilation speed? Atm Rust is no way the light nimble language they need it to be.

Runtime performance. This is mostly an LLVM versus GCC thing.

Runtime performance is 6232.525219 task-clock 533 context-switches 1 CPU-migrations 166 page-faults 27,385,819,080 cycles 19,494,722,200 stalled-cycles-frontend 6,403,657,640 stalled-cycles-backend 31,905,910,193 instructions 1,902,954,908 branches 39,925 branch-misses 6.239027874 seconds time elapsed Performance counter stats 6970.131625 task-clock 601 context-switches 5 CPU-migrations 1,024 page-faults 30,587,917,853 cycles 19,368,464,950 stalled-cycles-frontend 7,348,766,082 stalled-cycles-backend 36,479,184,126 instructions 2,404,008,283 branches 65,846 branch-misses 6.977211938 seconds time elapsed The C version is here: far more important to us than compiler speed—a fast-to-compile Web browser is useless if it loses to existing engines in UX or benchmarks (every cycle counts!)—but we continue to spend time on compiler speed, because it's important for developers.

> This is mostly an LLVM versus GCC thing.

So how does clang do on nbody.c?

I don't know which code Brendan was using, but using the http://shootout.alioth.debian.org/ implementations I ran some tests of my own:

  Performance counter stats for './nbody.gcc_run 50000000' (5 runs): #    0.999 CPUs utilized            ( +-  0.09% ) #    0.086 K/sec                    ( +-  0.43% ) #    0.000 K/sec                    ( +- 66.67% ) #    0.027 K/sec                    ( +-  0.15% ) #    4.394 GHz                      ( +-  0.05% ) [83.31%] #   71.19% frontend cycles idle     ( +-  0.07% ) [83.30%] #   23.38% backend  cycles idle     ( +-  0.21% ) [66.70%] #    1.17  insns per cycle #    0.61  stalled cycles per insn  ( +-  0.01% ) [83.37%] #  305.326 M/sec                    ( +-  0.05% ) [83.36%] #    0.00% of all branches          ( +- 31.16% ) [83.34%] ( +-  0.08% ) for './nbody_rustc 50000000' (5 runs): #    0.999 CPUs utilized            ( +-  0.07% ) #    0.086 K/sec                    ( +-  0.33% ) #    0.001 K/sec                    ( +-  7.41% ) #    0.147 K/sec                    ( +-  0.02% ) #    4.388 GHz                      ( +-  0.04% ) [83.31%] #   63.32% frontend cycles idle     ( +-  0.06% ) [83.34%] #   24.03% backend  cycles idle     ( +-  0.84% ) [66.69%] #    1.19  insns per cycle #    0.53  stalled cycles per insn  ( +-  0.01% ) [83.35%] #  344.901 M/sec                    ( +-  0.04% ) [83.35%] #    0.00% of all branches          ( +- 11.89% ) [83.33%] http://benchmarksgame.alioth.debian.org/u32/program.php?test... . It appears to be the fastest C verson on the site. The Rust version looks pretty gross (it's likely very old code), I'd like to try porting the C version to Rust (it's only 140 lines) and compare the results. Note also that I'm using a version of the compiler that's so new that it's not even in the official repo yet, containing optimizations for floating-point math.

Change the sqrt call to use the sqrtf32() intrinsic. That's the modification we made to make nbody fast.

The branch I'm on has already updated shootout-nbody.rs for the new intrinsics, which is the reason that it takes just 7 seconds instead of 11. :)

Reply on news.ycombinator.com