harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][icu] Bringing ICU level up to 3.8
Date Thu, 18 Oct 2007 10:15:40 GMT
Mark Hindess wrote:
> On 17 October 2007 at 16:32, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> Tim Ellison wrote:
>> I was running this on the IBM VME, and here's what I got (below).
>>
>> Interestingly the Java decoder was faster on the long string than the
>> native code.  The others are sufficiently similar to imply to me that
>> we should just keep it all in Java.
> 
> You mean remove the heuristic and remove the intel-contributed native
> code?  I guess that seems reasonable given these results; it would
> enable us to reduce the size of the code base (and jre footprint
> as discussed elsewhere) and concentrate our efforts on the java
> implementation.

Well I'm not quite there yet.  I was running on the IBM VME and only did
a modicum of testing on my uniprocessor laptop, so I would expect to get
a more compelling case before discarding any existing code.

> Of course, this is rather dependent on us being able to achieve similar
> results on DRLVM - so it would be interesting to see these results for
> that VM too.

Agreed, and on different OS / CPU combinations.

It may be that I am measuring the capabilities of the JIT, which
certainly makes a big difference:

(WinXP, Centrino, large string, w/ warm up cycles, IBM VME)

Jit off, non-direct buffer:

  Decoding time: 2193 millis
  Encoding time: 2634 millis

Jit off, direct buffer:

  Decoding time: 771 millis
  Encoding time: 2624 millis    <-- looks strange


Jit on, direct buffer:
  Decoding time: 751 millis
  Encoding time: 461 millis

Jit on, non-direct bufer:
  Decoding time: 420 millis
  Encoding time: 481 millis


Regards,
Tim

Mime
View raw message