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
