BigInt and BigFloat performance is poor

[raichu]

BigFloat operations generate unnecessary garbage (mainly to immutability, it seems), ctor, dtor copying and alloc/free operations in general (they may be cheap for a Float32, but not for a BigFloat --and it gets even worse with increased precision).
One (natural) result is, matrix multiplication has awful performance.

Sample test case (from a real-world program)

set_bigfloat_precision(256)

function mk(d)
    m = zeros(BigFloat, d, d)
    diag = randn(d)
    for i = 1:d
        m[i,i] = diag[i]
    end
    m[1,d] = 1
    m[d,1] = 1
    return m
end

function rn(d, m)
    diag = randn(d)
    for i = 1:d
        m[i,i] = diag[i]
    end
end

function main()
    dim = 40
    n = 1000

    A = mk(dim)
    B = mk(dim)

    for i = 1:n
        A *= B
        rn(dim, B)
    end
end

@profile main()
Profile.print()

I think BigFloat should be mutable, or at least there should a mutable version of it. Immutable BigFloats are just crazy and are guaranteed to perform very bad in Julia programs, unless some other clever way is found.

For comparison, the C++ equivalent of the above program (which uses only one temporary for matrix multiplication, but nevertheless makes a temporary copy of A during A = A*B, and makes no other allocations during the loop) runs at ~20x speed and uses 1/300x memory at the moment.

[JeffBezanson]

Simply making BigFloats mutable doesn't really solve the problem, since although our current slowness is crazy, mutable numbers are also crazy. Natural mathematical code uses an immutable style, and all our Number-related APIs and functions are designed for this. For example, a library function might contain

x = a
a = a+b

where the second line changes a but not x. If a and x were mutable, this code wouldn't take advantage of it. So we need something more clever, along the lines of issues #1115, #3424, and #249

[jtravs]

Did anyone find a workaround for this issue? I have also been hit by bad performance with BigFloat matrix multiplication etc.

[StefanKarpinski]

No. We could expose some mutating operations on BigFloats but it could really easily lead to very confusing behavior if not used with great care.

[stevengj]

Note that our BigFloat is currently technical defined as a mutable type. This is actually somewhat annoying, e.g. it means that Complex{BigFloat} has a memory layout incompatible with GNU mpc. See also #9826.

[skariel]

Pull request for Pooling BigInts opened #10084

[atthom]

Hello, I came across this issue from google "BigInt Julia performance".
It's been a few years and this issue is still open. Is there any update?

Thank you for your dedicated work on Julia.

[ultravioletcatastrophe]

Someone with permissions should label this with bignums

[stevengj]

See also #11202