Strange performance behavior

[Marius Muja]

Bill Baxter wrote:
> Bill Baxter wrote:
>> Marius Muja wrote:
>>> I have noticed the following strange (at least for me) performance 
>>> behavior with one of my programs. It is a program that does some 
>>> scientific computations and while trying to optimize it I noticed 
>>> that the code from case_B below executes faster (almost twice as 
>>> fast) as the code in case_A. This is a bit counterintuitive for me, 
>>> since in case _B there is also the cost of the function call (or 
>>> should be the same if the function is inlined).
>>> Can anybody shed some light on why it's behaving this way?
>>>
>>> case_A:
>>> -------------------------------
>>> foreach (i,index; indices) {
>>>    foreach (k, inout value; centers[belongs_to[i]])
>>>     value += vecs[index][k];
>>> }
>>> ----------------------------------
>>>
>>> case_B:
>>> -------------------------------
>>> void addTo(T,U)(T[] a, U[] b) {
>>>    foreach(index, inout value; a) {
>>>       value += b[index];
>>>    }
>>> }
>>> ....
>>> foreach (i,index; indices) {
>>>    addTo(centers[belongs_to[i]],vecs[index]);
>>> }
>>> _______________________________
>>
>> My guess would be the compiler's failure to optimize[*] away the 
>> [index] indexing in A.  So you do 2 lookups per iteration rather than 
>> just one.  If so then this should be just as fast as case_B:
>>
>> foreach (i,index; indices) {
>>    auto vecs_i = vecs[index];
>>    foreach (k, inout value; centers[belongs_to[i]])
>>       value += vecs_i[k];
>> }
>>
> Forgot the footnote!:
> 
> [*] It may not really be a failure of the optimizer -- maybe it's 
> unreasonably difficult to determine absolutely that vecs won't changed 
> by the operation '+= vecs[index][k]'.
> 
> --bb

Yes, that was it! Thanks for clearing this up for me.