This improves the spectralnorm shootout benchmark through a few vectors after
looking at the leading C implementation:
* The simd-based f64x2 is now used to parallelize a few computations
* RWLock usage has been removed. A custom `parallel` function was added as a
form of stack-based fork-join parallelism. I found that the contention on the
locks was high as well as hindering other optimizations.
This does, however, introduce one `unsafe` block into the benchmarks, which
previously had none.
In terms of timings, the before and after numbers are:
```
$ time ./shootout-spectralnorm-before
./shootout-spectralnorm-before 2.07s user 0.71s system 324% cpu 0.857 total
$ time ./shootout-spectralnorm-before 5500
./shootout-spectralnorm-before 5500 11.88s user 1.13s system 459% cpu 2.830 total
$ time ./shootout-spectralnorm-after
./shootout-spectralnorm-after 0.58s user 0.01s system 280% cpu 0.210 tota
$ time ./shootout-spectralnorm-after 5500
./shootout-spectralnorm-after 5500 3.55s user 0.01s system 455% cpu 0.783 total
```
Function arguments are (hopefully!) the last places where allocas don't
get proper markers for the end of their lifetimes. This means that this
code using 64 bytes of stack for the function arguments:
````rust
std::io::println("1");
std::io::println("2");
std::io::println("3");
std::io::println("4");
````
But with the proper lifetime markers, the slots can be reused, and
the arguments only need 16 bytes of stack.
All deprecation warnings have been converted to errors. This includes
the warning for multiple cfgs on one item. We'll leave that as an error
for some period of time to ensure that all uses are updated before the
behavior changes from "or" to "and".
Position independent code has fewer requirements in executables, so pass
the appropriate flag to LLVM in order to allow more optimization. At the
moment this means faster thread-local storage.
compiletest: compact "linux" "macos" etc.as "unix".
liballoc: remove a superfluous "use".
libcollections: remove invocations of deprecated methods in favor of
their suggested replacements and use "_" for a loop counter.
libcoretest: remove invocations of deprecated methods; also add
"allow(deprecated)" for testing a deprecated method itself.
libglob: use "cfg_attr".
libgraphviz: add a test for one of data constructors.
libgreen: remove a superfluous "use".
libnum: "allow(type_overflow)" for type cast into u8 in a test code.
librustc: names of static variables should be in upper case.
libserialize: v[i] instead of get().
libstd/ascii: to_lowercase() instead of to_lower().
libstd/bitflags: modify AnotherSetOfFlags to use i8 as its backend.
It will serve better for testing various aspects of bitflags!.
libstd/collections: "allow(deprecated)" for testing a deprecated
method itself.
libstd/io: remove invocations of deprecated methods and superfluous "use".
Also add #[test] where it was missing.
libstd/num: introduce a helper function to effectively remove
invocations of a deprecated method.
libstd/path and rand: remove invocations of deprecated methods and
superfluous "use".
libstd/task and libsync/comm: "allow(deprecated)" for testing
a deprecated method itself.
libsync/deque: remove superfluous "unsafe".
libsync/mutex and once: names of static variables should be in upper case.
libterm: introduce a helper function to effectively remove
invocations of a deprecated method.
We still see a few warnings about using obsoleted native::task::spawn()
in the test modules for libsync. I'm not sure how I should replace them
with std::task::TaksBuilder and native::task::NativeTaskBuilder
(dependency to libstd?)
Signed-off-by: NODA, Kai <nodakai@gmail.com>
`strftime` currently returns a `String`. This does not indicate that
this function may return an error due to to a malformed format string.
This change introduces a `ParseError` enum which indicates the type of
error that occurred. The return type of `strptime` was also changed to
use this new enum instead of returning `Result<String, String>`. Now,
all instances where `strftime` was used need to have their return value
checked to see if it were valid or not.
[breaking-change]
All deprecation warnings have been converted to errors. This includes
the warning for multiple cfgs on one item. We'll leave that as an error
for some period of time to ensure that all uses are updated before the
behavior changes from "or" to "and".
Doing so would incur deeply nested expansion of the tree with no useful
side effects. This is problematic for "wide" data types such as structs
with dozens of fields but where only a few are actually being matched or bound.
Most notably, matching a fixed slice would use a number of stack frames that
grows with the number of elements in the slice.
Fixes#17877.
Position independent code has fewer requirements in executables, so pass
the appropriate flag to LLVM in order to allow more optimization. At the
moment this means faster thread-local storage.
I previously avoided `#[inline]`ing anything assuming someone would come in and explain to me where this would be appropriate. Apparently no one *really* knows, so I'll just go the opposite way an inline everything assuming someone will come in and yell at me that such-and-such shouldn't be `#[inline]`.
==================
For posterity, iteration comparisons:
```
test btree::map::bench::iter_20 ... bench: 971 ns/iter (+/- 30)
test btree::map::bench::iter_1000 ... bench: 29445 ns/iter (+/- 480)
test btree::map::bench::iter_100000 ... bench: 2929035 ns/iter (+/- 21551)
test treemap::bench::iter_20 ... bench: 530 ns/iter (+/- 66)
test treemap::bench::iter_1000 ... bench: 26287 ns/iter (+/- 825)
test treemap::bench::iter_100000 ... bench: 7650084 ns/iter (+/- 356711)
test trie::bench_map::iter_20 ... bench: 646 ns/iter (+/- 265)
test trie::bench_map::iter_1000 ... bench: 43556 ns/iter (+/- 5014)
test trie::bench_map::iter_100000 ... bench: 12988002 ns/iter (+/- 139676)
```
As you can see `btree` "scales" much better than `treemap`. `triemap` scales quite poorly.
Note that *completely* different results are given if the elements are inserted in order from the range [0, size]. In particular, TrieMap *completely* dominates in the sorted case. This suggests adding benches for both might be worthwhile. However unsorted is *probably* the more "normal" case, so I consider this "good enough" for now.
compiletest needs to link to native crate, or at least the `rt` library.
(I tried using a dependency on `rustrt` instead, and that did not resolve the problem. But this does.)
Partially addresses #17883
