harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [classlib][performance] performance improvement for luni and nio_char modules - Harmony-1980
Date Fri, 27 Oct 2006 12:36:13 GMT
Vladimir,
+1 more question: between TM integration and HARMONY-1942 incorrect
behaviour of BBP could significantly slow down the execution.
Did you do your measurements with Harmony-1942 applied?

On 10/27/06, Vladimir Strigun <vstrigun@gmail.com> wrote:
>
> Mikhail,
>
> Not yet. As I mentioned in the thread I'm still working on Dacapo.
> I'll let you know if I find any improvements for JIT.
>
> Thanks,
> Vladimir.
>
> On 10/27/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > Vladimir,
> > I see you removed some arraycopy operations in your patch as not
> effective.
> > I'm Ok with your solution but what to know if JIT could solve the
> problem
> > generating more effective code? Do you have any suggestions for JIT
> here?
> >
> > On 10/27/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > >
> > > 10%-15%?  That's amazing.  How fast are we (DRLVM) compared to Sun 1.5
> > > using decapo?
> > >
> > > geir
> > >
> > >
> > > Vladimir Strigun wrote:
> > > > The optimization covers the following issues:
> > > > - java.nio.charset.CharsetDecoder and
> java.nio.charset.CharsetEncoder
> > > > Streaming decoding/encoding was removed. Analysis of API hotspots
> for
> > > > Dacapo shows that CharsetDecoder is frequently used almost in all
> > > > benchmark, especially in chart. We already discussed advantages of
> > > > streaming decoding but the fix shows significant performance
> > > > improvement on average for all Dacapo benchmarks. For instance,
> boost
> > > > for chart benchmark is about 16%. Paulex, you recently worked in
> > > > nio_char module and if I correctly remember you introduce streaming
> > > > operations, so could you please review the changes and let me know?
> > > > Since streaming operation was removed, tests have been slightly
> > > > modified as well (previous version of tests fails on RI).
> > > > - java.io.BufferedReader
> > > > readLine() method was slightly modified. Additional check whether
> some
> > > > characters available in cached buffer was added prior to main cycle.
> > > > - java.io.InputStreamReader
> > > > Cached char buffer was removed, read() , read(char[], int, int)
> > > > methods were rewritten. Current implementation of read(char[], int,
> > > > int) uses several invocation of System.arraycopy. Proposed solution
> > > > wraps char[] arguments within char buffer and therefore doesn't use
> > > > arraycopy. Decoding operation is also produced inside the method, so
> > > > fillBuf() has been removed
> > > >
> > > > Thoughts? Comments?
> > > >
> > > > Thanks,
> > > > Vladimir.
> > > >
> > > > On 10/26/06, Vladimir Strigun (JIRA) <jira@apache.org> wrote:
> > > >> [classlib][performance] performance improvement for luni and
> nio_char
> > > >> modules
> > > >>
> > >
> -----------------------------------------------------------------------------
> > > >>
> > > >>
> > > >>                 Key: HARMONY-1980
> > > >>                 URL:
> http://issues.apache.org/jira/browse/HARMONY-1980
> > > >>             Project: Harmony
> > > >>          Issue Type: Improvement
> > > >>          Components: Classlib
> > > >>            Reporter: Vladimir Strigun
> > > >>         Attachments: Harmony-1980.diff
> > > >>
> > > >> I've analyzed API frequently used in all Dacapo[1] benchmarks and
> > > >> found several places in luni and nio_char modules that can be
> > > >> improved. Suggested fix gives about 10-15% boost on average for
> Dacapo
> > > >> executed on DRLVM. I'll post more details to dev list.
> > > >> Attached fix contains modifications for the following classes:
> > > >> java.io.BufferedReader, java.io.InputStreamReader,
> > > >> java.nio.charset.CharsetDecoder and java.nio.charset.CharsetEncoder
> .
> > > >>
> > > >> Please have a look to the results of Dacapo execution (values are
> in
> > > >> millisec, so the less the better):
> > > >>
> > > >> Small workload
> > > >>
> > > >>        OrigBuild   Patched
> > > >> bloat   996,078 1024,85
> > > >> chart   1240,777        1068,112
> > > >> fop     250,433 232,957
> > > >> hsqldb  348,942 361,139
> > > >> jython  831,143 824,775
> > > >> lusearch        1854,95 1870,969
> > > >> luindex 339,45  231,314
> > > >> pmd     29,704  23,638
> > > >>
> > > >>
> > > >> default workload
> > > >>        OrigBuild   Patched
> > > >> bloat   168733,562      175493,467
> > > >> chart   31651,792       25681,751
> > > >> fop     2546,289        2512,045
> > > >> hsqldb  22873,608       13555,515
> > > >> jython  128207,303      92863,28
> > > >> lusearch        29425,991       30064,153
> > > >> luindex 17825,795       18083,898
> > > >> pmd     44548,724       40225,694
> > > >>
> > > >>
> > > >>
> > > >> [1] http://dacapobench.sourceforge.net
> > > >>
> > > >>
> > > >> --
> > > >> This message is automatically generated by JIRA.
> > > >> -
> > > >> If you think it was sent incorrectly contact one of the
> > > >> administrators:
> > > http://issues.apache.org/jira/secure/Administrators.jspa
> > > >> -
> > > >> For more information on JIRA, see:
> > > http://www.atlassian.com/software/jira
> > > >>
> > > >>
> > > >>
> > > >
> > >
> >
> >
> >
> > --
> > Mikhail Fursov
> >
> >
>



-- 
Mikhail Fursov

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message