Re: [Qemu-devel] [PATCH 00/57] target-i386 eflags cleanup and bmi/adx extensions

[Richard Henderson]

On 01/24/2013 08:57 AM, Laurent Desnogues wrote:
> On Thu, Jan 24, 2013 at 5:52 PM, Richard Henderson <address@hidden> wrote:
> > On 2013-01-24 08:46, Laurent Desnogues wrote:
> > > I gave a quick try a your branch. My host is an x86_64 CPU and I
> > > ran an i386 nbench in user mode.  It works but some parts of the
> > > benchmark are noticeably slower (>10%).  Is that expected?
> >
> > Nope.  Everything in there should be about speeding up...
> >
> > I'll have a look at it and see if there's something obvious.
>
> Let me know if you need more information or the binary (I compiled
> it some time ago with the oldest compiler I could find, gcc 2.96).

Would you look and see how much variability you're getting?  I had a 
quick look with a (newly built) nbench binary and don't see any speed 
regressions outside the error bars.

Built with gcc 4.7.2, 4 trials each:
>                 Master                          Eflags3                 
>                 Avg             Stddev          Avg             Stddev          
>  Change Error
> Num S           585.92          18.25           573.79          4.39            
>  -2.07% 3.12%
> String S        51.14           1.10            51.52           0.13            
>   0.73% 2.15%
> Bitfield        1.64E+008       4.04E+006       1.62E+008       8.63E+005       
>  -1.32% 2.46%
> FP Emu  85.65           1.81            114.74          1.18             33.97% 
> 2.12%
> Fourier 1365.03         28.79           2813.78         11.72           106.13% 
> 2.11%
> Assign  14.86           0.24            14.89           0.21              0.22% 
> 1.62%
> Idea            723.70          43.31           884.20          4.55            
>  22.18% 5.98%
> Huff            495.27          8.72            702.89          3.53            
>  41.92% 1.76%
> N Net           0.29            0.01            0.73            0.00            
> 149.99% 1.78%
> LU Decomp       9.26            0.16            21.91           0.22            
> 136.61% 1.70%

I haven't looked to see where the massive fp improvements come from, but 
my first guess is not storing cc_op so often.  Although perhaps it would 
keep us on the same page if we were talking about the exact same binary...


r~