Commit Graph

11 Commits

Author SHA1 Message Date
Matthias Krüger 1a6b930eeb clarify operator precedence 2020-02-26 12:43:37 +01:00
Nicholas Nethercote 100ff5a256 Revert u8to64_le changes from #68914.
`SipHasher128`'s `u8to64_le` function was simplified in #68914.
Unfortunately, the new version is slower, because it introduces `memcpy`
calls with non-statically-known lengths.

This commit reverts the change, and adds an explanatory comment (which
is also added to `libcore/hash/sip.rs`). This barely affects
`SipHasher128`'s speed because it doesn't use `u8to64_le` much, but it
does result in `SipHasher128` once again being consistent with
`libcore/hash/sip.rs`.
2020-02-21 10:11:35 +11:00
Nicholas Nethercote 9aea154e78 Improve u8to64_le.
This makes it faster and also changes it to a safe function. (Thanks to
Michael Woerister for the suggestion.) `load_int_le!` is also no longer
necessary.
2020-02-12 11:32:57 +11:00
Nicholas Nethercote f8a02864af Speed up SipHasher128.
The current code in `SipHasher128::short_write` is inefficient. It uses
`u8to64_le` (which is complex and slow) to extract just the right number of
bytes of the input into a u64 and pad the result with zeroes. It then
left-shifts that value in order to bitwise-OR it with `self.tail`.

For example, imagine we have a u32 input 0xIIHH_GGFF and only need three bytes
to fill up `self.tail`. The current code uses `u8to64_le` to construct
0x0000_0000_00HH_GGFF, which is just 0xIIHH_GGFF with the 0xII removed and
zero-extended to a u64. The code then left-shifts that value by five bytes --
discarding the 0x00 byte that replaced the 0xII byte! -- to give
0xHHGG_FF00_0000_0000. It then then ORs that value with self.tail.

There's a much simpler way to do it: zero-extend to u64 first, then left shift.
E.g. 0xIIHH_GGFF is zero-extended to 0x0000_0000_IIHH_GGFF, and then
left-shifted to 0xHHGG_FF00_0000_0000. We don't have to take time to exclude
the unneeded 0xII byte, because it just gets shifted out anyway! It also avoids
multiple occurrences of `unsafe`.

There's a similar story with the setting of `self.tail` at the method's end.
The current code uses `u8to64_le` to extract the remaining part of the input,
but the same effect can be achieved more quickly with a right shift on the
zero-extended input.

All that works on little-endian. It doesn't work for big-endian, but we
can just do a `to_le` before calling `short_write` and then it works.

This commit changes `SipHasher128` to use the simpler shift-based approach. The
code is also smaller, which means that `short_write` is now inlined where
previously it wasn't, which makes things faster again. This gives big
speed-ups for all incremental builds, especially "baseline" incremental
builds.
2020-02-10 15:54:14 +11:00
Mark Rousskov a06baa56b9 Format the world 2019-12-22 17:42:47 -05:00
Vadim Petrochenkov e118eb6c79 librustc_data_structures: Unconfigure tests during normal build 2019-08-02 01:59:01 +03:00
Igor Matuszewski ad62b4203c Fix clippy::precedence 2019-06-26 14:14:27 +02:00
Igor Matuszewski 6c93b47c01 Fix clippy::cast_losless 2019-06-26 14:11:58 +02:00
Alexander Regueiro c3e182cf43 rustc: doc comments 2019-02-10 23:42:32 +00:00
Mark Rousskov 2a663555dd Remove licenses 2018-12-25 21:08:33 -07:00
Michael Woerister 25014b5379 rustc_data_structures: Add implementation of 128 bit SipHash. 2017-10-16 14:44:40 +02:00