--- Comment #14 from tromey at gcc dot gnu dot org 2006-03-10 00:48 ---
I checked in a patch using memcpy and memcmp.
This didn't yield as dramatic a speedup for me, but did do ok.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from tromey at gcc dot gnu dot org 2006-03-10 00:39 ---
Subject: Bug 23495
Author: tromey
Date: Fri Mar 10 00:39:49 2006
New Revision: 111919
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111919
Log:
PR libgcj/23495:
* java/lang/natString.cc (_Jv
--- Comment #12 from tromey at gcc dot gnu dot org 2006-03-09 19:17 ---
Fair enough. I'm handling this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from greenrd at gcc dot gnu dot org 2006-03-08 14:39
---
Sorry, I can't submit patches to libjava because I'm tainted (except for the
packages that are new in Mustang, which I haven't seen). Even though this is a
small change, I prefer to err on the side of caution.
--
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-08 00:54 ---
Actually, Robin, could you send your current patch for this?
It seems like we should simply put it in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from tromey at gcc dot gnu dot org 2006-02-06 22:12 ---
This seems to have stalled.
I think my preferred solution here would be to use memcmp and
let gcc and glibc fight it out for the best implementation.
How far are we from having that be a reasonable approach?
--
t
--- 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 use
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-28
23:32 ---
Subject: Re: java.lang.String.equals is suboptimal
On Aug 28, 2005, at 7:25 PM, greenrd at greenrd dot org wrote:
>
> --- Additional Comments From greenrd at greenrd dot org
> 2005-08-28 23:25 -
On Aug 28, 2005, at 7:25 PM, greenrd at greenrd dot org wrote:
--- Additional Comments From greenrd at greenrd dot org
2005-08-28 23:25 ---
memcmp (which is compiled for i686 in fedora because it is part of
glibc) is
actually less efficient than the current code on my athlon! I was
--- Additional Comments From greenrd at greenrd dot org 2005-08-28 23:25
---
memcmp (which is compiled for i686 in fedora because it is part of glibc) is
actually less efficient than the current code on my athlon! I was so surprised,
I ran the memcmp benchmark again, and the results diff
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-22
21:54 ---
Robin, could you do another test where you use memcmp instead of
a hand-written loop?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23495
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20
19:41 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20
19:10 ---
Hmm, doing a profiling, I noticed that equals does its own loop instead of
using memcmp which is
most likely more efficient as memcmp is optimized for each target by the OS.
--
http://gcc.gnu.org/bugzi
--- Additional Comments From greenrd at greenrd dot org 2005-08-20 16:29
---
Created an attachment (id=9549)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9549&action=view)
Benchmark
This is the equality benchmark I used. Uncomment the //ca [0] = 'b'; line and
negate the assertion
14 matches
Mail list logo
