qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Laurent Desnogues
Subject: Re: [Qemu-devel] [PATCH 00/57] target-i386 eflags cleanup and bmi/adx extensions
Date: Sat, 26 Jan 2013 14:27:35 +0100

On Thu, Jan 24, 2013 at 9:37 PM, Richard Henderson <address@hidden> wrote:
> 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...

Here are my results (5 runs):

          master                 eflags3                eflags3
                       stddev                 stddev    /master
NUMERIC SO      488.59      3.82      507.37      3.87    1.04
STRING SOR       42.10      0.27       43.51      0.13    1.03
BITFIELD  105344000.00 885426.45 91472800.00 426835.68    0.87
FP EMULATI       22.70      0.54       23.07      0.38    1.02
FOURIER        2669.56     16.12     2576.34     29.46    0.97
ASSIGNMENT        8.40      0.11        7.68      0.02    0.91
IDEA           1535.88      7.73     1620.72      3.80    1.06
HUFFMAN         212.21      2.08      214.34      1.28    1.01
NEURAL NET        0.75      0.00        0.76      0.00    1.01
LU DECOMPO       24.25      0.06       24.75      0.08    1.02

Host is an i7-920 running gcc 4.6.1 x86_64.
nbench was compiled with gcc 2.96 targetting 32-bit.  The binary
I have is old and has been stripped and I alas have no access to
gcc 2.96 anymore.  Note that using a more recent compiler doesn't
show that much difference.


Laurent



reply via email to

[Prev in Thread] Current Thread [Next in Thread]