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 <kcarlsso...@gmail.com>
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.
>>
>>
