On 2/10/08, Tim Ellison <[EMAIL PROTECTED]> wrote: > Good work Tony. Perhaps a wiki page or umbrella JIRA would help us > track these? I think they may get lost in mail discussion.
That's right. Update to wiki page http://wiki.apache.org/harmony/MigrateToICU > > Just my 2c. > Tim > > Tony Wu wrote: > > On 2/7/08, Pavel Pervov <[EMAIL PROTECTED]> wrote: > >> Tony, > >> > >> Unfortunately, I have a number of JIRAs for you. They all are > >> regressions after removing duplicate locale data. > >> > >> Here they go: > >> > > Hi, Pavel and all > > my solution below > > > >> https://issues.apache.org/jira/browse/HARMONY-5459 > > Fixed, thanks for your patch. > >> https://issues.apache.org/jira/browse/HARMONY-5461 > > Can not reproduce > >> https://issues.apache.org/jira/browse/HARMONY-5465 > > Reported to ICU before. ICU refused to fix but we can work around it > > if necessary. Need your suggestion. > >> https://issues.apache.org/jira/browse/HARMONY-5466 > > non-bug difference, due to CLDR data. > >> https://issues.apache.org/jira/browse/HARMONY-5467 > > non-bug difference, due to CLDR data. > >> https://issues.apache.org/jira/browse/HARMONY-5468 > > report to http://bugs.icu-project.org/trac/ticket/6174 > >> https://issues.apache.org/jira/browse/HARMONY-5469 > > I suppose it is another CLDR data difference, need your commets. > > > > > >> I would like to know your opinion on whether they should be fixed of > >> resolved some other way. > >> > >> Thanks, > >> Pavel. > >> > >> P.S. There is also HARMONY-5013 which was introduced with moving to > >> ICU4J 3.8. Could you, please, look at that issue too? > >> > >> On 1/23/08, Tony Wu <[EMAIL PROTECTED]> wrote: > >>> Thanks very much, so we got 4MB src code cutted w/o pay. Cheer! > >>> > >>> On 1/23/08, Aleksey Shipilev <[EMAIL PROTECTED]> wrote: > >>>> Hi Tony, > >>>> > >>>> The good thing is, after the commit I have compared revisions 610727 > >>>> (before your commit) and 612866 (after your commit) and haven't > >>>> noticed degradation while running SPECjbb2005 in 2-VM configuration. > >>>> That's definitely good news :) > >>>> > >>>> Thanks, > >>>> Aleksey. > >>>> > >>>> On Jan 21, 2008 10:17 AM, Tony Wu <[EMAIL PROTECTED]> wrote: > >>>>> Thanks, Aleksey and all > >>>>> > >>>>> patch committed at r612718. Then I'm going to deal with the non-bug > >>>>> difference. Hopefully many legcy bugs/differences can be fixed this > >>>>> time. > >>>>> > >>>>> > >>>>> On 1/17/08, Aleksey Shipilev <[EMAIL PROTECTED]> wrote: > >>>>>> Hi, guys! > >>>>>> > >>>>>> Sure, correctness is important, but performance is important too. I > >>>>>> had profiled both versions (clean and patched) and see no significant > >>>>>> difference there: there are more GC happens what I believe connected > >>>>>> to internal ICU object creation and such. So, there are no obvious way > >>>>>> to maintain the same performance level, and may be we will try again > >>>>>> to eliminate ICU usage from the hotpath of frequently used workloads - > >>>>>> but previous investigation shows it's not that simple. > >>>>>> > >>>>>> Tony, please go ahead with committing this patch, we will deal with > >>>>>> ICU performance issues a little later. > >>>>>> > >>>>>> Thanks, > >>>>>> Aleksey. > >>>>>> > >>>>>> On Jan 15, 2008 1:52 PM, Tony Wu <[EMAIL PROTECTED]> wrote: > >>>>>>> Hi Aleksey, > >>>>>>> > >>>>>>> Thanks for you help. > >>>>>>> > >>>>>>> I've proved there is no performance degradation on my machine > >>>>>>> mentioned in my previous mail. I suppose the different result on your > >>>>>>> machine is caused by different options to SpecJBB. Anyway, my POV is > >>>>>>> that we should be willing to pay for the adoption of ICU if we have > >>>>>>> to. All of us should be positive on this point. I'd like to clarify > >>>>>>> the factors I'm facing below. > >>>>>>> > >>>>>>> Firstly, the original implementation of harmony is faster but > >>>>>>> incorrect. It is not reasonable to keep the code as is and refuse to > >>>>>>> correct it just because the bad version has better performance. IMHO > >>>>>>> performance is nothing if there is no correctness. > >>>>>>> > >>>>>>> Secondly, we adopt ICU through delegation which involves extra method > >>>>>>> calls than we implement it by ourselves, it does harm to performance > >>>>>>> and can not be worked around. But please do not forget we benefit from > >>>>>>> ICU in bug fixing, maintenance, smaller code size and so on. > >>>>>>> > >>>>>>> Lastly, branching does not make sense to me. My fix is very separate > >>>>>>> in luni and text, I can not guarantee that there is no modification > >>>>>>> during my work, so the synchronization between HEAD and my branch is > >>>>>>> required. Actually only I myself am working on the development work > >>>>>>> (Surely, Aleksey is very helpful on testing), this synchronization > >>>>>>> might be a nightmare to me. Furthermore, the code on branch will not > >>>>>>> be automatically tested by continuous integration system and BTI, I do > >>>>>>> not want to work without collaboration, that's not an open source > >>>>>>> style, right? Will you ask a contributor to create a branch and play > >>>>>>> with himself whenever he wants to contribute? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 1/15/08, Mark Hindess <[EMAIL PROTECTED]> wrote: > >>>>>>>> On 14 January 2008 at 16:21, Tim Ellison <[EMAIL PROTECTED]> wrote: > >>>>>>>>> Aleksey Shipilev wrote: > >>>>>>>>>> Yep, Tim, you're right. I believe that new implementation fixes a > >>>>>>>>>> number of bugs and will try to get it not degrading. I just want to > >>>>>>>>>> maintain the performance level of current trunk on the same level, > >>>>>>>>>> gradually fixing functional bugs. I don't like to sacrifice > >>>>>>>>>> performance of HEAD revision for non-critical bugfix. That is, I > >>>>>>>>>> want > >>>>>>>>>> to see HEAD changes like this: > >>>>>>>>>> > >>>>>>>>>> "high performance, minor bug -> high performance, no bugs" > >>>>>>>>>> > >>>>>>>>>> rather than > >>>>>>>>>> > >>>>>>>>>> "high performance, minor bug -> low performance, no bugs -> high > >>>>>>>>>> performance, no bugs" > >>>>>>>>>> > >>>>>>>>>> ...because anyone could get the HEAD Harmony revision for > >>>>>>>>>> performance measurements at any time. > >>>>>>>> Couldn't someone also get the HEAD Harmony revision and suffer from > >>>>>>>> the > >>>>>>>> known/fixable-with-Tony's-patch bugs at any time? > >>>>>>>> > >>>>>>>>>> What do you think? > >>>>>>>>> For sure, improving performance and fixing the bugs is the most > >>>>>>>>> desirable state. I actually don't mind some minor performance > >>>>>>>>> regression on HEAD between releases provided it is an area being > >>>>>>>>> actively worked upon. > >>>>>>>> +1 especially if it fixes bugs > >>>>>>>> > >>>>>>>>> I'd also like to get to 4.2Mb source code reduction too ;-) > >>>>>>>> Me too. > >>>>>>>> > >>>>>>>>> If you and Tony are happy to work on the patch to get it perfect > >>>>>>>>> then > >>>>>>>>> go ahead. I hope it is not too troublesome to keep it in synch. > >>>>>>>>> You > >>>>>>>>> could also consider a branch in SVN. > >>>>>>>> This bothers me too. Firstly, while it is being developed in patch > >>>>>>>> on JIRA, it is likely only Tony and Aleksey will really look at it. > >>>>>>>> Secondly, that progress will be slow because of the cost of keeping > >>>>>>>> in > >>>>>>>> sync - this applies to an SVN branch too. > >>>>>>>> > >>>>>>>> I can't help thinking we'll make more progress if we apply the patch > >>>>>>>> to > >>>>>>>> HEAD now. We'll get wider visibility of problems with the new code - > >>>>>>>> and there are likely issues beyond the performance problems that have > >>>>>>>> been the focus so far - and more people will see the benefit of Tony > >>>>>>>> (and Aleksey's) hard work in getting us to this point. > >>>>>>>> > >>>>>>>> I certainly don't want all this work to be completed outside svn HEAD > >>>>>>>> and committed a week or two before the freeze for next milestone. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Mark. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> Tony Wu > >>>>>>> China Software Development Lab, IBM > >>>>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> Tony Wu > >>>>> China Software Development Lab, IBM > >>>>> > >>> > >>> -- > >>> Tony Wu > >>> China Software Development Lab, IBM > >>> > >> > >> -- > >> Pavel Pervov, > >> Intel Enterprise Solutions Software Division > >> > > > > > -- Tony Wu China Software Development Lab, IBM
