Auto merge of #27110 - arthurprs:optintstr, r=Gankro
I wrote a reasonably optimized version for both functions. Further optimizations are possible but I tried to keep the code size small (which I think is important), it's a road of diminished gains.
The repository used for testing/benchmarks is https://github.com/arthurprs/rust-optimized-inttostr
Benchmarks are ran for 3 different distributions, bellow are string length histograms for the u32 type
Tested processors are
* x64 laptop (i7-2670QM)
* x32 server (Digital Ocean E5-2630L-v2)
### Display
It uses a small look up table (200 bytes) and decode up to 4 characters at a time. I also took special precautions to reduce 64bit arithmetic on 32bit architectures and the gains are huge in these cases.
Overall, on modern 64bit CPUs it's pretty much the same speed as the stdlib implementation for very small numbers (0..99), but pulls ahead as the length of the decimal increases. On slight older CPUs (w/ worse ALUs) or 32bit architectures it's pretty much always faster.
x64 benchmarks
```
test bench::display_h_new_u08 ... bench: 71,041 ns/iter (+/- 2,894)
test bench::display_h_new_u16 ... bench: 378,255 ns/iter (+/- 36,547)
test bench::display_h_new_u32 ... bench: 4,232,483 ns/iter (+/- 509,661)
test bench::display_h_new_u64 ... bench: 5,166,740 ns/iter (+/- 421,124)
test bench::display_h_stdlib_u08 ... bench: 73,536 ns/iter (+/- 5,287)
test bench::display_h_stdlib_u16 ... bench: 451,443 ns/iter (+/- 16,879)
test bench::display_h_stdlib_u32 ... bench: 5,551,070 ns/iter (+/- 518,151)
test bench::display_h_stdlib_u64 ... bench: 8,624,374 ns/iter (+/- 643,701)
test bench::display_l_new_u08 ... bench: 71,547 ns/iter (+/- 504)
test bench::display_l_new_u16 ... bench: 399,727 ns/iter (+/- 28,030)
test bench::display_l_new_u32 ... bench: 4,365,303 ns/iter (+/- 414,414)
test bench::display_l_new_u64 ... bench: 5,302,382 ns/iter (+/- 292,324)
test bench::display_l_stdlib_u08 ... bench: 75,445 ns/iter (+/- 2,487)
test bench::display_l_stdlib_u16 ... bench: 444,313 ns/iter (+/- 16,203)
test bench::display_l_stdlib_u32 ... bench: 5,761,801 ns/iter (+/- 387,186)
test bench::display_l_stdlib_u64 ... bench: 8,790,365 ns/iter (+/- 614,846)
test bench::display_m_new_u08 ... bench: 71,820 ns/iter (+/- 2,956)
test bench::display_m_new_u16 ... bench: 399,649 ns/iter (+/- 20,643)
test bench::display_m_new_u32 ... bench: 4,355,561 ns/iter (+/- 179,189)
test bench::display_m_new_u64 ... bench: 5,070,594 ns/iter (+/- 341,950)
test bench::display_m_stdlib_u08 ... bench: 74,900 ns/iter (+/- 1,909)
test bench::display_m_stdlib_u16 ... bench: 448,788 ns/iter (+/- 20,791)
test bench::display_m_stdlib_u32 ... bench: 5,717,939 ns/iter (+/- 316,824)
test bench::display_m_stdlib_u64 ... bench: 8,787,160 ns/iter (+/- 482,864)
```
x86 benchmarks
```
test bench::display_h_new_u08 ... bench: 94,246 ns/iter (+/- 34,872)
test bench::display_h_new_u16 ... bench: 533,805 ns/iter (+/- 22,499)
test bench::display_h_new_u32 ... bench: 6,127,747 ns/iter (+/- 2,192,789)
test bench::display_h_new_u64 ... bench: 14,994,203 ns/iter (+/- 1,609,345)
test bench::display_h_stdlib_u08 ... bench: 107,233 ns/iter (+/- 8,571)
test bench::display_h_stdlib_u16 ... bench: 631,186 ns/iter (+/- 11,332)
test bench::display_h_stdlib_u32 ... bench: 7,696,344 ns/iter (+/- 957,917)
test bench::display_h_stdlib_u64 ... bench: 45,677,401 ns/iter (+/- 4,991,344)
test bench::display_l_new_u08 ... bench: 95,855 ns/iter (+/- 27,735)
test bench::display_l_new_u16 ... bench: 532,084 ns/iter (+/- 40,479)
test bench::display_l_new_u32 ... bench: 5,973,953 ns/iter (+/- 211,676)
test bench::display_l_new_u64 ... bench: 14,773,064 ns/iter (+/- 1,276,579)
test bench::display_l_stdlib_u08 ... bench: 106,350 ns/iter (+/- 63,963)
test bench::display_l_stdlib_u16 ... bench: 637,746 ns/iter (+/- 101,005)
test bench::display_l_stdlib_u32 ... bench: 7,740,640 ns/iter (+/- 848,478)
test bench::display_l_stdlib_u64 ... bench: 44,846,932 ns/iter (+/- 4,514,694)
test bench::display_m_new_u08 ... bench: 94,549 ns/iter (+/- 13,029)
test bench::display_m_new_u16 ... bench: 546,030 ns/iter (+/- 35,804)
test bench::display_m_new_u32 ... bench: 5,983,924 ns/iter (+/- 1,180,559)
test bench::display_m_new_u64 ... bench: 14,817,873 ns/iter (+/- 2,271,464)
test bench::display_m_stdlib_u08 ... bench: 107,806 ns/iter (+/- 8,805)
test bench::display_m_stdlib_u16 ... bench: 630,714 ns/iter (+/- 6,586)
test bench::display_m_stdlib_u32 ... bench: 7,784,210 ns/iter (+/- 358,601)
test bench::display_m_stdlib_u64 ... bench: 46,223,927 ns/iter (+/- 6,553,176)
```
### from_str_radix (FromStr)
All valid digits are ascii so I modified the function to use the underlining bytes instead and simplified the match to avoid wasting cycles.
x64 benchmarks
```
test bench::from_str_h_new_u08 ... bench: 28,153 ns/iter (+/- 624)
test bench::from_str_h_new_u16 ... bench: 223,513 ns/iter (+/- 11,554)
test bench::from_str_h_new_u32 ... bench: 3,098,935 ns/iter (+/- 231,022)
test bench::from_str_h_new_u64 ... bench: 5,009,900 ns/iter (+/- 341,961)
test bench::from_str_h_stdlib_u08 ... bench: 34,033 ns/iter (+/- 2,068)
test bench::from_str_h_stdlib_u16 ... bench: 248,785 ns/iter (+/- 14,208)
test bench::from_str_h_stdlib_u32 ... bench: 4,150,536 ns/iter (+/- 266,070)
test bench::from_str_h_stdlib_u64 ... bench: 6,817,997 ns/iter (+/- 449,838)
test bench::from_str_l_new_u08 ... bench: 27,552 ns/iter (+/- 1,500)
test bench::from_str_l_new_u16 ... bench: 234,360 ns/iter (+/- 13,144)
test bench::from_str_l_new_u32 ... bench: 3,140,261 ns/iter (+/- 248,175)
test bench::from_str_l_new_u64 ... bench: 5,176,583 ns/iter (+/- 350,416)
test bench::from_str_l_stdlib_u08 ... bench: 35,060 ns/iter (+/- 2,154)
test bench::from_str_l_stdlib_u16 ... bench: 252,135 ns/iter (+/- 23,461)
test bench::from_str_l_stdlib_u32 ... bench: 4,154,599 ns/iter (+/- 369,606)
test bench::from_str_l_stdlib_u64 ... bench: 6,892,767 ns/iter (+/- 213,030)
test bench::from_str_m_new_u08 ... bench: 28,252 ns/iter (+/- 1,384)
test bench::from_str_m_new_u16 ... bench: 231,051 ns/iter (+/- 16,540)
test bench::from_str_m_new_u32 ... bench: 3,166,504 ns/iter (+/- 134,418)
test bench::from_str_m_new_u64 ... bench: 5,103,195 ns/iter (+/- 218,912)
test bench::from_str_m_stdlib_u08 ... bench: 35,012 ns/iter (+/- 2,735)
test bench::from_str_m_stdlib_u16 ... bench: 250,967 ns/iter (+/- 14,708)
test bench::from_str_m_stdlib_u32 ... bench: 4,101,845 ns/iter (+/- 205,802)
test bench::from_str_m_stdlib_u64 ... bench: 6,823,001 ns/iter (+/- 267,215)
```
x86 benchmarks
```
test bench::from_str_h_new_u08 ... bench: 23,682 ns/iter (+/- 3,590)
test bench::from_str_h_new_u16 ... bench: 190,916 ns/iter (+/- 29,688)
test bench::from_str_h_new_u32 ... bench: 2,649,952 ns/iter (+/- 308,576)
test bench::from_str_h_new_u64 ... bench: 23,458,434 ns/iter (+/- 2,327,427)
test bench::from_str_h_stdlib_u08 ... bench: 45,551 ns/iter (+/- 6,968)
test bench::from_str_h_stdlib_u16 ... bench: 313,739 ns/iter (+/- 17,175)
test bench::from_str_h_stdlib_u32 ... bench: 4,615,669 ns/iter (+/- 470,766)
test bench::from_str_h_stdlib_u64 ... bench: 30,589,482 ns/iter (+/- 2,278,996)
test bench::from_str_l_new_u08 ... bench: 23,763 ns/iter (+/- 5,545)
test bench::from_str_l_new_u16 ... bench: 185,472 ns/iter (+/- 33,097)
test bench::from_str_l_new_u32 ... bench: 2,691,307 ns/iter (+/- 473,886)
test bench::from_str_l_new_u64 ... bench: 22,952,593 ns/iter (+/- 1,963,742)
test bench::from_str_l_stdlib_u08 ... bench: 45,285 ns/iter (+/- 16,337)
test bench::from_str_l_stdlib_u16 ... bench: 313,624 ns/iter (+/- 6,643)
test bench::from_str_l_stdlib_u32 ... bench: 4,595,679 ns/iter (+/- 1,876,361)
test bench::from_str_l_stdlib_u64 ... bench: 30,434,683 ns/iter (+/- 1,901,996)
test bench::from_str_m_new_u08 ... bench: 23,812 ns/iter (+/- 1,505)
test bench::from_str_m_new_u16 ... bench: 185,553 ns/iter (+/- 19,788)
test bench::from_str_m_new_u32 ... bench: 2,614,920 ns/iter (+/- 66,230)
test bench::from_str_m_new_u64 ... bench: 23,241,778 ns/iter (+/- 3,474,077)
test bench::from_str_m_stdlib_u08 ... bench: 45,634 ns/iter (+/- 1,436)
test bench::from_str_m_stdlib_u16 ... bench: 316,479 ns/iter (+/- 21,212)
test bench::from_str_m_stdlib_u32 ... bench: 4,609,147 ns/iter (+/- 487,068)
test bench::from_str_m_stdlib_u64 ... bench: 30,165,173 ns/iter (+/- 1,601,830)
```
Auto merge of #27101 - steveklabnik:doc_no_mutability_root, r=Gankro
And some other outdated language. @echochamber came asking about these docs
on IRC today, and they're a bit weird. I've updated them to be less ambiguous
and use contemporary terminology.
Auto merge of #27099 - AlisdairO:diagnostics3, r=Manishearth
Per the title. I've linked to the reference at http://doc.rust-lang.org/reference.html#type-parameters-1, but I'm not sure that's such a good link - but there doesn't seem to be a great deal of explanation elsewhere in the reference either...
Auto merge of #27085 - Ryman:gh17546, r=alexcrichton
This also changes how variant values are printed in errors, they are no
longer printed in their parent scope. As far as I can tell, this is
leftover from pre-namespacing of enums.
Auto merge of #26955 - Gankro:raw-vec, r=bluss,alexcrichton
Per the top level comment:
A low-level utility for more ergonomically allocating, reallocating, and deallocating a
a buffer of memory on the heap without having to worry about all the corner cases
involved. This type is excellent for building your own data structures like Vec and VecDeque.
In particular:
* Produces heap::EMPTY on zero-sized types
* Produces heap::EMPTY on zero-length allocations
* Catches all overflows in capacity computations (promotes them to "capacity overflow" panics)
* Guards against 32-bit systems allocating more than isize::MAX bytes
* Guards against overflowing your length
* Aborts on OOM
* Avoids freeing heap::EMPTY
* Contains a ptr::Unique and thus endows the user with all related benefits
This type does not in anyway inspect the memory that it manages. When dropped it *will*
free its memory, but it *won't* try to Drop its contents. It is up to the user of RawVec
to handle the actual things *stored* inside of a RawVec.
Note that a RawVec always forces its capacity to be usize::MAX for zero-sized types.
This enables you to use capacity growing logic catch the overflows in your length
that might occur with zero-sized types.
However this means that you need to be careful when roundtripping this type
with a `Box<[T]>`: `cap()` won't yield the len. However `with_capacity`,
`shrink_to_fit`, and `from_box` will actually set RawVec's private capacity
field. This allows zero-sized types to not be special-cased by consumers of
this type.
Steve Klabnik [Fri, 17 Jul 2015 22:50:42 +0000 (18:50 -0400)]
Remove confusing 'mutability root' term
And some other outdated language. @echochamber came asking about these docs
on IRC today, and they're a bit weird. I've updated them to be less ambiguous
and use contemporary terminology.
Rollup merge of #26777 - barosl:macro-doc-escapes, r=pnkfelix
Escape sequences in documentation comments must not be parsed as a normal string when expanding a macro, otherwise some innocent but invalid-escape-sequence-looking comments will trigger an ICE.
Although this commit replaces normal string literals with raw string literals in macro expansion, this shouldn't be much a problem considering documentation comments are converted into attributes before being passed to a macro anyways.
Auto merge of #27045 - nikomatsakis:better-object-defaults-error, r=pnkfelix
Transition to the new object lifetime defaults, replacing the old defaults completely.
r? @pnkfelix
This is a [breaking-change] as specified by [RFC 1156][1156] (though all cases that would break should have been receiving warnings starting in Rust 1.2). Types like `&'a Box<Trait>` (or `&'a Rc<Trait>`, etc) will change from being interpreted as `&'a Box<Trait+'a>` to `&'a Box<Trait+'static>`. To restore the old behavior, write the `+'a` explicitly. For example, the function:
Auto merge of #27076 - alexcrichton:update-llvm, r=brson
LLVM has recently created their 3.7 release branch, and this PR updates us to that point. This should hopefully mean that we're basically compatible with the upcoming 3.7 release. Additionally, there are a number of goodies on this branch.
* This contains a fix for https://llvm.org/bugs/show_bug.cgi?id=23957
which should help us bootstrap farther on 32-bit MSVC targets.
* There is better support for writing multiple flavors of archives, allowing us
to use the built-in LLVM support instead of the system `ar` on all current
platforms of the compiler.
* This LLVM has SafeStack support
* An [optimization patch](https://github.com/rust-lang/llvm/commit/7cf5e26e18f7d2d8db09c83c76dd727535f281ab) by @pcwalton is included.
* A number of other minor test fixes here and there.
Due to problems dealing with the data layout we pass to LLVM, this PR also takes the time to clean up how we specific this. We no longer specify a data layout to LLVM by default and instead take the default for the target from LLVM to pass to the module that we're building. This should be more robust going into the future, and I'm also not sure we know what any of these arcane strings are any more...
Kevin Butler [Fri, 17 Jul 2015 14:16:22 +0000 (15:16 +0100)]
Improve error message for variant values used as types
This also changes how variant values are printed in errors, they are no
longer printed in their parent scope. As far as I can tell, this is
leftover from pre-namespacing of enums.
Rollup merge of #25993 - nham:fix_23969, r=nikomatsakis
Adds two error codes, one for duplicate associated constants and one for types. I'm not certain these should each have their own code, but E0201 is already solely for duplicate associated functions so at least it kinda matches. This will lead to somewhat redundant error explanations, but that's nothing new!
Auto merge of #27066 - rust-lang:rollup_central, r=steveklabnik
Everything on this branch has passed check-stage2 on linux.
This is a temporary integration branch until [our buildbot problems](https://internals.rust-lang.org/t/buildbot-is-down-for-a-bit/2365/3) get fixed.
As the day progresses I'll merge more PRs into this branch once I get them through make check.
This branch isn't complete, keeping it up here so more people can merge PRs into integration if they want.
Alex Crichton [Thu, 16 Jul 2015 22:48:16 +0000 (15:48 -0700)]
trans: Clean up handling the LLVM data layout
Turns out for OSX our data layout was subtly wrong and the LLVM update must have
exposed this. Instead of fixing this I've removed all data layouts from the
compiler to just use the defaults that LLVM provides for all targets. All data
layouts (and a number of dead modules) are removed from the compiler here.
Custom target specifications can still provide a custom data layout, but it is
now an optional key as the default will be used if one isn't specified.
Alex Crichton [Thu, 16 Jul 2015 07:11:09 +0000 (00:11 -0700)]
trans: Add kind to writeArchive
Updates our LLVM bindings to be able to write out multiple kinds of archives.
This commit also enables using LLVM instead of the system ar on all current
targets.
Alex Crichton [Tue, 30 Jun 2015 15:56:56 +0000 (08:56 -0700)]
rustc_trans: Update LLVMBuildLandingPad signature
The C API of this function changed so it no longer takes a personality function.
A shim was introduced to call the right LLVM function (depending on which
version we're compiled against) to set the personality function on the outer
function.
The compiler only ever sets one personality function for all generated
functions, so this should be equivalent.
Alex Crichton [Tue, 30 Jun 2015 15:18:44 +0000 (08:18 -0700)]
Update LLVM
There's a number of goodies in this LLVM update:
* This contains a fix for https://llvm.org/bugs/show_bug.cgi?id=23957
which should help us bootstrap farther on 32-bit MSVC targets.
* There is better support for writing multiple flavors of archives, allowing us
to use the built-in LLVM support instead of the system `ar` on all current
platforms of the compiler.
* A number of other minor bug fixes and performance improvements to unblock
various other pieces of work.
projects / rust.git / log