Hi, Aleksey. With a quick look I think the problem is in code generation/selection and there are two files in jitrino - Ia32CodeGenerator.cpp and Ia32CodeSelector.cpp. I'm planning to use the simple case you mentioned to do some tracing and hope to find the problem. Any comments?
Xiaoming > > -----Original Message----- > From: Aleksey Shipilev [mailto:[EMAIL PROTECTED] > Sent: Friday, July 04, 2008 5:31 PM > To: [email protected] > Subject: Re: [general][performance] Stefan Krause's Harmony performance > evaluation > > Hi Xiaoming! > > Yep, I would really appreciate it. Do you need an assistance on this topic? > > Thanks, > Aleksey. > > > -----Original Message----- > > From: Xiao-Feng Li [mailto:[EMAIL PROTECTED] > > Sent: Friday, July 04, 2008 4:55 PM > > To: Gu, Xiaoming > > Subject: Fwd: [general][performance] Stefan Krause's Harmony performance > evaluation > > > > ---------- Forwarded message ---------- > > From: Aleksey Shipilev <[EMAIL PROTECTED]> > > Date: 2008/7/4 > > Subject: Re: [general][performance] Stefan Krause's Harmony > > performance evaluation > > To: [email protected] > > > > > > Hi Gregory, all, > > > > The performance is important for JRE too. > > > > BTW, I had profiled spectralnorm benchmark and see following problems: > > > > 1. Bad instruction selection for integer divide: > > > > int a; > > int b = a / 2; > > > > generates into: > > > > mov eax, a > > mov ebx, 2 > > idiv eax, ebx > > > > but it's better to > > > > mov eax, a > > shl eax, 1 > > > > Manual change in Java code brings +60% to spectralnorm performance > > (execution time downs from 10secs to 6secs). There should be better > > instruction selection for divide operation. Would someone take it? If > > not, I would try to produce the patch for Jitrino this weekend. > > > > > > 2. Recompilation events propagation > > > > Consider the following call chain: > > main() --[n times]--> A() --[m times]--> B() > > > > Now consider, m >> n, then B() should be inlined. But such the > > inlining will be done during the recompilation of method A(), which > > waits for n to rise up (that's true for current server.emconf with > > edge profiler enabled). On first glance, one of the solutions will be > > propagation of such recompilation requests up the call chain. Any > > ideas here are welcome. > > > > Thanks, > > Aleksey. > > > > On Fri, Jul 4, 2008 at 1:04 AM, Gregory Shimansky <[EMAIL PROTECTED]> > wrote: > >> On 4 июля 2008 Aleksey Shipilev wrote: > >>> TWIMC, > >>> > >>> Stefan Krause publishes another review on Java vs. C performance here: > >>> http://www.stefankrause.net/wp/?p=9#comments > >>> > >>> It seems like Harmony has "a long way to go" in performance :) > >>> I'm gonna look on some of these tests in near term. > >> > >> It is interesting to see that IBM is often quite close to Harmony in > >> performance. In fact Harmony acts quite well in its current state. I > think > >> though that performance for Java is always a 2nd priority after > stability. > >> Look at IBM, its Java is targeted at servers where stability is what is > >> important. > >> > >> Looking at the occasional test failures on the alerts mail list it seems > like > >> stability is the number one focus for improvement and it is a by far > harder > >> to move in that direction. > >> > >> -- > >> Gregory > >> > > > > > > > > -- > > http://xiao-feng.blogspot.com > > >
