diff options
| author | Eduard-Mihai Burtescu <edy.burt@gmail.com> | 2016-11-09 20:51:15 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2016-11-09 20:51:15 +0200 |
| commit | dc8ac2679aa1c52d5860a2e6514cf7ed89b7d445 (patch) | |
| tree | b2ac410427544892ea9179110d1bc66b0bd1cf24 /src/test/incremental/thinlto | |
| parent | 2321d11b8c8b10ac7727826bdfbe6a326d46cc34 (diff) | |
| parent | 00e48affde2d349e3b3bfbd3d0f6afb5d76282a7 (diff) | |
| download | rust-dc8ac2679aa1c52d5860a2e6514cf7ed89b7d445.tar.gz rust-dc8ac2679aa1c52d5860a2e6514cf7ed89b7d445.zip | |
Rollup merge of #37229 - nnethercote:FxHasher, r=nikomatsakis
Replace FNV with a faster hash function.
Hash table lookups are very hot in rustc profiles and the time taken within `FnvHash` itself is a big part of that. Although FNV is a simple hash, it processes its input one byte at a time. In contrast, Firefox has a homespun hash function that is also simple but works on multiple bytes at a time. So I tried it out and the results are compelling:
```
futures-rs-test 4.326s vs 4.212s --> 1.027x faster (variance: 1.001x, 1.007x)
helloworld 0.233s vs 0.232s --> 1.004x faster (variance: 1.037x, 1.016x)
html5ever-2016- 5.397s vs 5.210s --> 1.036x faster (variance: 1.009x, 1.006x)
hyper.0.5.0 5.018s vs 4.905s --> 1.023x faster (variance: 1.007x, 1.006x)
inflate-0.1.0 4.889s vs 4.872s --> 1.004x faster (variance: 1.012x, 1.007x)
issue-32062-equ 0.347s vs 0.335s --> 1.035x faster (variance: 1.033x, 1.019x)
issue-32278-big 1.717s vs 1.622s --> 1.059x faster (variance: 1.027x, 1.028x)
jld-day15-parse 1.537s vs 1.459s --> 1.054x faster (variance: 1.005x, 1.003x)
piston-image-0. 11.863s vs 11.482s --> 1.033x faster (variance: 1.060x, 1.002x)
regex.0.1.30 2.517s vs 2.453s --> 1.026x faster (variance: 1.011x, 1.013x)
rust-encoding-0 2.080s vs 2.047s --> 1.016x faster (variance: 1.005x, 1.005x)
syntex-0.42.2 32.268s vs 31.275s --> 1.032x faster (variance: 1.014x, 1.022x)
syntex-0.42.2-i 17.629s vs 16.559s --> 1.065x faster (variance: 1.013x, 1.021x)
```
(That's a stage1 compiler doing debug builds. Results for a stage2 compiler are similar.)
The attached commit is not in a state suitable for landing because I changed the implementation of FnvHasher without changing its name (because that would have required touching many lines in the compiler). Nonetheless, it is a good place to start discussions.
Profiles show very clearly that this new hash function is a lot faster to compute than FNV. The quality of the new hash function is less clear -- it seems to do better in some cases and worse in others (judging by the number of instructions executed in `Hash{Map,Set}::get`).
CC @brson, @arthurprs
Diffstat (limited to 'src/test/incremental/thinlto')
0 files changed, 0 insertions, 0 deletions
