improve performance for number to string conversion functions

[KristofferC]

This is kinda silly but it is what it is...

Benchmark:

for base in (2, 8, 10, 16)
    @btime begin
        u = rand(UInt32)
        string(u; base=$base)
    end
end

Before

  385.406 ns (2 allocations: 118 bytes)
  168.925 ns (2 allocations: 96 bytes)
  131.273 ns (2 allocations: 96 bytes)
  149.896 ns (2 allocations: 96 bytes)

After

  72.232 ns (2 allocations: 118 bytes)
  49.118 ns (2 allocations: 96 bytes)
  61.106 ns (2 allocations: 96 bytes)
  68.188 ns (2 allocations: 96 bytes)

[KristofferC]

Noticed this when looking into the parse_int regression reported in JuliaLang/www.julialang.org#139.

[KristofferC]

The following patch also manages to speed it up:

diff --git a/base/char.jl b/base/char.jl
index 700c61db27c..d071a3988bd 100644
--- a/base/char.jl
+++ b/base/char.jl
@@ -108,10 +108,14 @@ and [`show_invalid`](@ref).
 """
 isoverlong(c::AbstractChar) = false

-function UInt32(c::Char)
+@inline function UInt32(c::Char)
     # TODO: use optimized inline LLVM
     u = reinterpret(UInt32, c)
     u < 0x80000000 && return u >> 24
+    return _uint32(u)
+end
+
+@noinline function _uint32(u::UInt32)
     l1 = leading_ones(u)
     t0 = trailing_zeros(u) & 56
     (l1 == 1) | (8l1 + t0 > 32) |
@@ -142,8 +146,12 @@ that support overlong encodings should implement `Base.decode_overlong`.
 """
 decode_overlong

-function Char(u::UInt32)
+@inline function Char(u::UInt32)
     u < 0x80 && return reinterpret(Char, u << 24)
+    return _char(u)
+end
+
+@noinline function _char(u::UInt32)
     u < 0x00200000 || code_point_err(u)::Union{}
     c = ((u << 0) & 0x0000003f) | ((u << 2) & 0x00003f00) |
         ((u << 4) & 0x003f0000) | ((u << 6) & 0x3f000000)

It is a bit more general but I guess might slow things down if the old Char function inlined and you are dealing with non ASCII a lot?

[johnfgibson]

That is great. Any chance there's a similar fix for a performance regression in the print_to_file microbenchmark? It went from 6.86 in julia-0.6.4 to 10.8 in julia-0.7.0 and 1.0.0. The core of the benchmark is

for i = 1:n
    @printf(io, "%d %d\n", i, i + 1)
end

[jebej]

Maybe use Int('0') for clarity?

[KristofferC]

That is great. Any chance there's a similar fix for a performance regression in the print_to_file microbenchmark? It went from 6.86 in julia-0.6.4 to 10.8 in julia-0.7.0 and 1.0.0. The core of the benchmark is

There are, in general, String regressions a bit here and there. I'll see if there is some simple fix that can be applied like here.

[KristofferC]

Maybe use Int('0') for clarity?

That kills performance.

[KristofferC]

For now, I think we should go with this "local" performance improvement and then we can look at a perhaps more general but more intrusive change like #28661 (comment).

[jebej]

That kills performance.

Argh, I've been using this type of pattern. Isn't the conversion done at compile time? Why would it be worse than just '0'?

[KristofferC]

Argh, I've been using this type of pattern. Isn't the conversion done at compile time? Why would it be worse than just '0'?

It should be and in some cases it does.

julia> f() = UInt8('0')
f (generic function with 1 method)

julia> @code_llvm f()

; Function f
; Location: REPL[4]:1
define i8 @julia_f_34955() {
top:
  ret i8 48
}

But for some reason, it doesn't seem to happen here. Not sure why.

[vtjnash]

Typically, we handle that case by writing it thusly:

@eval function f() = begin
    some_computation($(some_constant_computation(some_constants)))
end