Hi, Oliver! This change: a. does not affect composite Dacapo performance b. degrades SPECjbb2005 performance for 1-2%.
Taking (b) into the account, I would like to vote for deferring immediate moving to ICU 3.8.1. We can revisit this one more time if there's a way to beat the degradation. Thanks, Aleksey. On Dec 14, 2007 3:53 PM, Oliver Deakin <[EMAIL PROTECTED]> wrote: > Thanks for offering to help Aleksey, that's great! > > Ive opened HARMONY-5313 and attached a script and a patch to be applied. > Please run the script before applying the patch, as one file needs to be > moved before it is patched. Once it's applied, if you run the > fetch-depends target you should see that the new ICU4J jars are > downloaded. Then if you just rebuild you should be ready to run with the > new version. > > Thanks for the help! > Oliver > > > Aleksey Shipilev wrote: > > Thanks, Oliver! > > > > Performance data on microtests is looking good, however I wonder what > > impact it has on DRLVM and large benchmarks. Haven't you filed JIRA > > for this issue? If I'll have exact steps to build configuration with > > new ICU, I could check it's performance before committing the changes > > to the trunk. > > > > Aleksey. > > > > On Dec 13, 2007 8:08 PM, Oliver Deakin <[EMAIL PROTECTED]> wrote: > > > >> Thanks Aleksey. > >> > >> I have run the JUnit tests with the IBM VME and they pass without any > >> new failures. I have also run the encoding/decoding test in HARMONY-3709 > >> a number of times - in general, ICU4J 3.8.1 performs in that test as > >> well or slightly better than the ICU4J 3.8 jar we are currently using. I > >> have attached the results of the latest run I made [1]. > >> > >> Regards, > >> Oliver > >> > >> [1] > >> DECODING: > >> Small Input: > >> Decoding: GB18030 , 1000000 times > >> Current ICU4J Milliseconds: 890.0 > >> ICU4J 3.8.1 Milliseconds: 593.0 > >> Small Input: > >> Decoding: ISO-8859-1 , 1000000 times > >> Current ICU4J Milliseconds: 328.0 > >> ICU4J 3.8.1 Milliseconds: 328.0 > >> Small Input: > >> Decoding: UTF-8 , 1000000 times > >> Current ICU4J Milliseconds: 344.0 > >> ICU4J 3.8.1 Milliseconds: 360.0 > >> Large Input: > >> Decoding: GB18030 , 1000 times > >> Current ICU4J Milliseconds: 2110.0 > >> ICU4J 3.8.1 Milliseconds: 1968.0 > >> Large Input: > >> Decoding: ISO-8859-1 , 1000 times > >> Current ICU4J Milliseconds: 157.0 > >> ICU4J 3.8.1 Milliseconds: 156.0 > >> Large Input: > >> Decoding: UTF-8 , 1000 times > >> Current ICU4J Milliseconds: 735.0 > >> ICU4J 3.8.1 Milliseconds: 719.0 > >> > >> ENCODING: > >> Small Input: > >> Encoding: GB18030 , 1000000 times > >> Current ICU4J Milliseconds: 969.0 > >> ICU4J 3.8.1 Milliseconds: 1063.0 > >> Small Input: > >> Encoding: ISO-8859-1 , 1000000 times > >> Current ICU4J Milliseconds: 344.0 > >> ICU4J 3.8.1 Milliseconds: 344.0 > >> Small Input: > >> Encoding: UTF-8 , 1000000 times > >> Current ICU4J Milliseconds: 359.0 > >> ICU4J 3.8.1 Milliseconds: 359.0 > >> Large Input: > >> Encoding: GB18030 , 1000 times > >> Current ICU4J Milliseconds: 7407.0 > >> ICU4J 3.8.1 Milliseconds: 7297.0 > >> Large Input: > >> Encoding: ISO-8859-1 , 1000 times > >> Current ICU4J Milliseconds: 219.0 > >> ICU4J 3.8.1 Milliseconds: 219.0 > >> Large Input: > >> Encoding: UTF-8 , 1000 times > >> Current ICU4J Milliseconds: 625.0 > >> ICU4J 3.8.1 Milliseconds: 610.0 > >> > >> > >> > >> Aleksey Shipilev wrote: > >> > >>> Good news, Oliver! > >>> > >>> Anyway, basing on our previous experiences with ICU changes, we might > >>> first try how Harmony performs with new ICU onboard before making this > >>> change default. That's not only JUnit and other validation suites, but > >>> performance too (say, Dacapo and other benchmarks performance). > >>> > >>> Thanks, > >>> Aleksey. > >>> > >>> > >>> On Dec 13, 2007 2:53 PM, Oliver Deakin <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>> ICU 3.8.1 has just been released, so Id like to propose that after M4 we > >>>> upgrade to this release, add it to the fetch-depends target and remove > >>>> the "homemade" ICU4J jar we have stored in SVN. > >>>> > >>>> Im running the tests with the new version now to make sure there are no > >>>> regressions and will be happy to make the required changes when the time > >>>> comes. > >>>> > >>>> Objections? > >>>> > >>>> Regards, > >>>> Oliver > >>>> > >>>> -- > >>>> Oliver Deakin > >>>> Unless stated otherwise above: > >>>> IBM United Kingdom Limited - Registered in England and Wales with number > >>>> 741598. > >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > >>>> 3AU > >>>> > >>>> > >>>> > >>>> > >>> > >> -- > >> > >> Oliver Deakin > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with number > >> 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > >> > >> > >> > > > > > > -- > > Oliver Deakin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > >
