Uninitialize working memory

[termoshtt]

Split from #241

Current implementation uses zero-initialization like

let mut work = vec![Self::zero(); n];

This will initialize work memory using memset, which would be fastest to initialize memory. This memory initialization make our code safe for accessing like work[i], however, this is relatively heavy comparing to uninitialized code:

let mut work = Vec::with_capacity(n);
unsafe { work.set_len(n) };

This takes O(1) time while initialization needs O(n) time, but access work[i] causes undefined behavior even if i < n.
Because LAPACK routines are assured not to read work memory, this uninitialized version can be used.

This cost is usually neglectable comparing to most LAPACK routines, which often takes O(n^2) or O(n^3) for large n. But if we focus on the memory allocation cost #241 #168, it should be considered, and split them to evaluate memory allocation cost properly.

Alternative

let work = vec![std::mem::MaybeUninit::uninit(); n];

could be another way. It actually does not initialize the memory, and almost same performance as above uninitialized version. I do not use it on this PR because some API, especially slice_get_mut is not stabilized yet. This will be better choice for future rustc where they are stabilized.

Links

• Fast vector initialization without default value -- Rust Program Language Forum

[codecov]

Codecov Report

Merging #243 into master will increase coverage by 0.01%.
The diff coverage is 93.33%.

@@            Coverage Diff             @@
##           master     #243      +/-   ##
==========================================
+ Coverage   89.07%   89.08%   +0.01%     
==========================================
  Files          71       71              
  Lines        3588     3592       +4     
==========================================
+ Hits         3196     3200       +4     
  Misses        392      392              

Impacted Files	Coverage Δ
lax/src/solveh.rs	78.78% <66.66%> (ø)
lax/src/eig.rs	89.00% <81.81%> (ø)
lax/src/eigh.rs	94.44% <83.33%> (ø)
lax/src/least_squares.rs	100.00% <100.00%> (ø)
lax/src/lib.rs	100.00% <100.00%> (ø)
lax/src/opnorm.rs	100.00% <100.00%> (ø)
lax/src/qr.rs	100.00% <100.00%> (ø)
lax/src/rcond.rs	100.00% <100.00%> (ø)
lax/src/solve.rs	100.00% <100.00%> (ø)
lax/src/svd.rs	100.00% <100.00%> (ø)
... and 3 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 73d4e77...dc2ab7d. Read the comment docs.

[termoshtt]

Needs benchmark code

[termoshtt]

I have confirmed this PR have small (~0.1 us, ~10%) performance gain for svddc/C/4 benchmark by #244, though they cannot split from noise for larger matrices.