On 10/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
This is a nice note to wake up to...
Vladimir Strigun wrote:
> Here are the results:
>
> Small workload:
> OrigBuild Fixed Sun1.5.0_06
> bloat 996,078 1024,85 955,589
> chart 1240,777 1068,112 953,096
> fop 250,433 232,957 174,901
> hsqldb 348,942 361,139 540,45
> jython 831,143 824,775 571,292
> lusearch 1854,95 1870,969 1830,589
> luindex 339,45 231,314 441,79
> pmd 29,704 23,638 61,638
>
> Average 449,91 408,60 471,71
>
> default workload:
> OrigBuild Fixed Sun1.5.0_06
> bloat 16116,691 15618 13578,522
> chart 11701,546 10036,631 9790,247
> fop 2539,386 2502,518 2387,289
> hsqldb 3217,338 3078,331 5709,291
> jython 14639,278 14064,104 9456,167
> lusearch 14508,938 16175,085 13663,679
> luindex 16292,652 15501,713 15602,178
> pmd 10840,264 12937,255 9734,032
>
> Average 9337,73 9281,87 8787,42
>
> large workload:
> OrigBuild Fixed Sun1.5.0_06
> bloat 168733,5 175493,46 138468,277
> chart 31651,79 25681,751 25599,38
> fop 2546,289 2512,045 2412,487
> hsqldb 22873,608 13555,515 15751,873
> jython 128207,3 92863,28 26183,716
> lusearch 29425,991 30064,153 26605,631
> luindex 17825,795 18083,898 14307,71
> pmd 44548,724 40225,694 46345,995
>
> Average 31345,21 27334,72 22348,3525
>
> At first glace the results are pretty good, but antlr benchmark works
> incorrectly with DRLVM (Harmony-1906) and there are no results for
> eclipse and xalan benchmarks. I'm still working on Dacapo analysis.
"Pretty good"? You're suggesting that DRLVM is faster than Sun 1.5. I
would say "Wow!", not "pretty good..."
More info - what is "OrigBuild" and what is "Fixed"? Why is "Fixed"
slower than "OrigBuild"?
"Fixed" is the same build plus H-1980 included. As you can see from
"average" rows "Fixed" build is faster. The values are in millisec, so
the less the better, i.e. we are still slower that RI.
Thanks,
Vladimir.
geir
>
> Thanks,
> Vladimir.
>
> On 10/26/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> 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
>> >>
>> >>
>> >>
>> >
>>
>
