On Fri, 27 Apr 2012 20:03:48 -0400, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:

> On 28/04/12 00:29, Era Scarecrow wrote:
>> Last try adding ref after const; At the off chance it's shallow copying, this
>> should remove that.
>
> Ahhh, that works.  Thank you!
>
> Back story: originally the reputation() function just took the array ratings and made an internal copy, ratings_, which was used by the rest of the code.  I took that out in this commit: https://github.com/WebDrake/Dregs/commit/4d2a8a055321c2981a453fc4d82fb781da2ea5c7
>
> ... because I found I got about a 2s speedup.  It's exactly the speedup which was removed by adding "const" to the function input, so I presume it's as you say, that this was implicitly creating a local copy.

Try removing the ref and see if it goes back.  That usage of ref should not affect anything (if anything it should be slower, since it's an extra level of indirection).

There is no implicit local copy for const.  I have a suspicion that you changed two things and forgot about one of them when running your tests.

-Steve

On 30/04/12 16:03, Steven Schveighoffer wrote:
> Try removing the ref and see if it goes back. That usage of ref should not
> affect anything (if anything it should be slower, since it's an extra level of
> indirection).

Removing the ref ups the time as described before, but only with GDC (DMD the runtime is the same).  It's a real effect.

> There is no implicit local copy for const. I have a suspicion that you changed
> two things and forgot about one of them when running your tests.

Really don't think so.  You can even check the version history of changes if you like!

Joseph Rushton Wakeling:

> Removing the ref ups the time as described before, but only with GDC (DMD the runtime is the same).  It's a real effect.
>
>> There is no implicit local copy for const. I have a suspicion that you changed
>> two things and forgot about one of them when running your tests.
>
> Really don't think so.  You can even check the version history of changes if you like!

Then it's seems a compiler bug. Please, minimize it as much as
possible, and put it in Bugzilla.

Bye,
bearophile

On Wed, 02 May 2012 16:05:13 -0400, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:

> On 30/04/12 16:03, Steven Schveighoffer wrote:
>> Try removing the ref and see if it goes back. That usage of ref should not
>> affect anything (if anything it should be slower, since it's an extra level of
>> indirection).
>
> Removing the ref ups the time as described before, but only with GDC (DMD the runtime is the same).  It's a real effect.

I'm not familiar with GDC, but as bearophile says, it sounds like a compiler bug.  Maybe GDC is making an optimization in one case and not in the other, but both should be equivalently able to get the optimization.

>
>> There is no implicit local copy for const. I have a suspicion that you changed
>> two things and forgot about one of them when running your tests.
>
> Really don't think so.  You can even check the version history of changes if you like!

IIRC, your original post concerned not-checked in code.  Anyway, if you've re-run the tests, this is a confirmation.  I'd go ahead and file a bug against GDC.  Rest assured, const should not *slow down* anything.

-Steve

On 05/03/12 16:07, Steven Schveighoffer wrote:
> On Wed, 02 May 2012 16:05:13 -0400, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> 
>> On 30/04/12 16:03, Steven Schveighoffer wrote:
>>> Try removing the ref and see if it goes back. That usage of ref should not affect anything (if anything it should be slower, since it's an extra level of indirection).
>>
>> Removing the ref ups the time as described before, but only with GDC (DMD the runtime is the same).  It's a real effect.
> 
> I'm not familiar with GDC, but as bearophile says, it sounds like a compiler bug.  Maybe GDC is making an optimization in one case and not in the other, but both should be equivalently able to get the optimization.
> 
>>
>>> There is no implicit local copy for const. I have a suspicion that you changed two things and forgot about one of them when running your tests.
>>
>> Really don't think so.  You can even check the version history of changes if you like!
> 
> IIRC, your original post concerned not-checked in code.  Anyway, if you've re-run the tests, this is a confirmation.  I'd go ahead and file a bug against GDC.  Rest assured, const should not *slow down* anything.

There *was* a GDC bug some time ago, where a 'const' or 'in' function argument prevented inlining. Iain fixed it, so unless an old GDC version is used, it's probably not related.

http://forum.dlang.org/thread/jdhb57$10vf$1@digitalmars.com?page=16#post-mailman.33.1325763631.16222.d.gnu:40puremagic.com

artur

On 03/05/12 16:07, Steven Schveighoffer wrote:
> IIRC, your original post concerned not-checked in code. Anyway, if you've re-run
> the tests, this is a confirmation. I'd go ahead and file a bug against GDC. Rest
> assured, const should not *slow down* anything.

Yes, with the original post I was hoping there might be a quick answer that would avoid anyone having to go through the details of my code, e.g. a known issue or reason.  But I can confirm that the effect is real and consistent; I tested it again just now, and it even scales with the system size.

I've made some attempts to construct a minimal example, as opposed to my rather complicated code, but so far have been unable to reproduce the effect with a simple case. :-(  What I could do is try and cut away from the existing code and see where the effect vanishes, or prepare a set of single-file versions of the code with no qualifiers, const alone, and const ref respectively.

On 03/05/12 16:59, Artur Skawina wrote:
> There *was* a GDC bug some time ago, where a 'const' or 'in' function argument
> prevented inlining. Iain fixed it, so unless an old GDC version is used, it's
> probably not related.

I'm running GDC 4.6.3; I don't know if this fix made it into that release.  It would make sense if faulty inlining was responsible, though.

On 04/05/12 18:07, Joseph Rushton Wakeling wrote:
> On 03/05/12 16:59, Artur Skawina wrote:
>> There *was* a GDC bug some time ago, where a 'const' or 'in' function argument
>> prevented inlining. Iain fixed it, so unless an old GDC version is used, it's
>> probably not related.
>
> I'm running GDC 4.6.3; I don't know if this fix made it into that release. It
> would make sense if faulty inlining was responsible, though.

Let me clarify that last statement.  The core function in the struct is one that does something like this (pseudocode):

    auto myMainFunc(Rating[] x)
    {
        do {
            myFunc1(x);
            myFunc2(x);
            myFunc3(x);
            /* calculate exit-condition value*/
        } while (/* conditions not met */)

        return results;
    }

So, if I'm putting in const (or const ref) qualifiers, they're being applied to the inputs of myMainFunc, myFunc1, myFunc2 and myFunc3.  These 3 are obvious candidates for compiler inlining, so anything which affects the possibility of this happening could be expected to hit performance.

(... in the real code, myMainFunc() is called reputation(); the 3 interior functions are respectively userDivergence(), userReputation() and objectReputation().)