It's actually a regression of more than a factor of 2 on the machine I'm using.
I'll try to further refine the commit range by hand today. Bill. On Wednesday, 16 March 2016 20:45:00 UTC+1, Bill Hart wrote: > > I can only partially bisect. > > The regression happens between: > > 75fc9104ee24 (more recent) > > and > > dc6b0de80550 (older) > > But few of the intervening commits actually build, so I can't refine it > further. There's something like 40 commits in that range. > > Bill. > > On 16 March 2016 at 18:28, Kristoffer Carlsson <[email protected]> > wrote: > >> Can you bisect to the right commit? >> >> You can create a julia script that runs "exit(1)" on a bad commit and " >> exit(0)" on a good commit. >> >> Then create a bisect_runner.sh with >> >> make || exit 125 >> >> julia -e 'include("test_script.jl")' >> >> and then do a bisect run ./bisect_runner.sh after having marked a good >> and bad commit. >> >> >> >> On Wednesday, March 16, 2016 at 5:25:11 PM UTC+1, Bill Hart wrote: >>> >>> We are seeing a performance regression with a factor of 1.5 or 2.0 >>> (depending on machine) for the following simple C interface code between >>> 0.4.2 and today's master (not sure where the problem initially showed up, >>> but within the last 50 days): >>> >>> import Base: + >>> >>> typealias ZZ Array{UInt, 1} >>> >>> function +(a::ZZ, b::Int) >>> r = ZZ(length(a)) >>> ccall((:__gmpn_add_1, :libgmp), Void, (Ptr{UInt}, Ptr{UInt}, Int, >>> Int), r, a, 3, b) >>> return r >>> end >>> >>> function doit(n::Int) >>> a = ZZ(3) >>> a[1] = rand(UInt) >>> a[2] = rand(UInt) >>> a[3] = rand(UInt) >>> >>> for s = 1:n >>> a += s >>> end >>> >>> return a >>> end >>> >>> doit(1000000000) >>> >>> >>> I realise the example is not mathematically very meaningful, nor is it >>> the best way to compute anything in particular. It's cut down from a larger >>> example to illustrate the performance regression clearly. >>> >>> Bill. >>> >>> >
