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
> 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(10)
>>>
>>>
>>> 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.
>>>
>>>
>
