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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


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.



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/