Re: [hatari-devel] Issues with cache hits/misses?

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 01/06/2015 16:02, Douglas Little a écrit :

> It might be due to the dynamically calculated shift size and the size of
> the type being shifted, resulting in the compiler just generating some
> unnecessarily pedantic code.
>
> However such a trivial thing seems to be a strange source of performance
> drop on a modern PC. I'd suspect something else is going on...

Yes, this is very strange.

In the case of the word accesses, we only have 2 cases : aligned=0 or 2 
(because TOS was not built to access words on odd addresses).

So, if I replace :

        } else if (size == 1 && aligned <= 2) {
                v1 >>= (2 - aligned) * 8;
                return v1;
        }

by

        } else if (size == 1 && aligned == 0) {
//                                return get_word (addr+aligned);
                v1 >>= 16;
                return v1;
        }
        else if (size == 1 && aligned == 2) {
                return v1;
        }

Then this is still slow, even if the shift is constant, meaning that the 
slow down is in "v1 >>= 16" ?! That's really weird ...

Well, since at this point we already handled if that was a hit or a 
miss+cache update, this means the value in the cache is supposed to be 
the same as the content at "addr+aligned", so we could just return 
directly the content at this address instead of shifting v1, but this 
still looks like bypassing some compiler's strangeness to me.

Maybe I should try to compile with clang to see if that's different.