[Bug libgcj/23495] java.lang.String.equals is suboptimal

[greenrd at greenrd dot org]

------- Additional Comments From greenrd at greenrd dot org  2005-08-30 01:17 -------
(In reply to comment #7)
> This seems like something glibc's memcmp should be doing also, could
> you report a bug to glibc about this comparison?

Actually I was wrong - it's not glibc's memcmp that's being used here, it's the
gcc inlined memcmp (see http://sources.redhat.com/bugzilla/show_bug.cgi?id=1262
), which uses the "CISC-style" instructions REP MOVSB. This performs badly in
_every_ case on athlon-xp compared to a "RISC-style" loop. (Indeed this is
documented - it's surprising that gcc has been using the wrong substitution for
so long!) So I will submit a more conservative bug about changing the inlined
memcmp into a loop, against gcc. And will test it on pentium 4 as well.

The block-compare is harder to argue for at the gcc level because it is quite
complicated for the case of memcmp on big-endian (see the glibc implementation)
and therefore probably isn't a good case for inlining, at least not on x86.

However, the block-compare makes perfect sense for the simpler case of
java.lang.String.equals, as my results show.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23495