Optimize integer-->string conversions

[kimikage]

This avoids invalidations caused by invalidating StringVector(::Integer). (cf. PR #36459) (Edit: The problem has been solved by PR #36459.)
This also makes bin(), dec() and hex() slightly faster, but does not change the Printf.

julia> versioninfo() # on WSL
Julia Version 1.6.0-DEV.312
Commit 6185d24ac3 (2020-06-28 22:42 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-9.0.1 (ORCJIT, skylake)

julia> @btime string.(x, base=2) setup=(x=rand(Int64,1000));
  57.300 μs (2001 allocations: 151.67 KiB) # before
  38.400 μs (2001 allocations: 151.69 KiB) # after

julia> @btime string.(x, base=8) setup=(x=rand(Int64,1000));
  34.700 μs (2001 allocations: 117.30 KiB) # before
  34.800 μs (2001 allocations: 117.30 KiB) # after

julia> @btime string.(x, base=10) setup=(x=rand(Int64,1000));
  45.900 μs (2001 allocations: 117.27 KiB) # before
  35.400 μs (2001 allocations: 117.28 KiB) # after

julia> @btime string.(x, base=10) setup=(x=rand(Int32,1000));
  35.300 μs (2001 allocations: 101.69 KiB) # before
  31.300 μs (2001 allocations: 101.69 KiB) # after

julia> @btime string.(x, base=16) setup=(x=rand(Int64,1000));
  38.300 μs (2001 allocations: 115.84 KiB) # before
  33.600 μs (2001 allocations: 115.80 KiB) # after

[JeffBezanson]

Awesome!

[timholy]

This is a pretty performance-sensitive operation, so unrolling those loops is a great idea.

[kimikage]

@rfourquet, I appreciate your comment

I added the clamping into the string(), and changed the types of the pad of internal functions (e.g. bin()) from Integer to Int. Although we can leave them as Integer for "compatibility", I think there are no practical advantages.

I don't know the reason, but there is a little slowdown (~1 ns/number) from the original commit, but the unrolling is still effective.

[timholy]

Bumping this. I don't have any objections to merging this.

[kimikage]

Since PR #36459 was merged, the ::Int for leading_zeros(x) doesn't seem to be needed anymore.

[musm]

Looks like this PR has been approved, is it ok to merge?

[StefanKarpinski]

I've kicked off the failed CI runs, which looked unrelated. This seems good once CI passes.

[kimikage]

Thanks!

[kimikage]

I'm sorry, but I may have broken something.
cc: @rfourquet
https://github.com/JuliaCI/NanosoldierReports/blob/c1103cd2398e1d0442f115264893823991742a66/pkgeval/by_date/2020-10/01/logs/BitIntegers/1.6.0-DEV-2fe2b43606.log

Edit:
Perhaps the cause is the type of bit shifting.

julia/base/intfuncs.jl

Line 633 in 36effbe

x >>= 0x4

Can you fix this on the BitIntegers.jl side? (cf. rfourquet/BitIntegers.jl#13)

[rfourquet]

Perhaps the cause is the type of bit shifting.

@kimikage Thank you for the report, I had no idea this x << 0x4 was broken in BitIntegers.