qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] Re: [Qemu-commits] [COMMIT a4b18c6] tcg/x86_64: generated dec/inc instead of sub/addwhen possible
       [not found] <200909271613.n8RGDCLo020606@d01av04.pok.ibm.com>
@ 2009-09-28  7:51 ` Avi Kivity
  2009-09-28  8:21   ` Laurent Desnogues
  0 siblings, 1 reply; 5+ messages in thread
From: Avi Kivity @ 2009-09-28  7:51 UTC (permalink / raw)
  To: Aurelien Jarno; +Cc: qemu-devel@nongnu.org

On 09/27/2009 06:13 PM, Anthony Liguori wrote:
> From: Aurelien Jarno<aurelien@aurel32.net>
>    

Intel recommends not using inc/dec.  Since these instructions don't 
update all of the flags, they cannot be issued in parallel to previous 
instructions that do.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Qemu-devel] Re: [Qemu-commits] [COMMIT a4b18c6] tcg/x86_64: generated dec/inc instead of sub/addwhen possible
  2009-09-28  7:51 ` [Qemu-devel] Re: [Qemu-commits] [COMMIT a4b18c6] tcg/x86_64: generated dec/inc instead of sub/addwhen possible Avi Kivity
@ 2009-09-28  8:21   ` Laurent Desnogues
  2009-09-29 15:51     ` Filip Navara
  0 siblings, 1 reply; 5+ messages in thread
From: Laurent Desnogues @ 2009-09-28  8:21 UTC (permalink / raw)
  To: Avi Kivity; +Cc: qemu-devel@nongnu.org, Aurelien Jarno

On Mon, Sep 28, 2009 at 9:51 AM, Avi Kivity <avi@redhat.com> wrote:
> On 09/27/2009 06:13 PM, Anthony Liguori wrote:
>>
>> From: Aurelien Jarno<aurelien@aurel32.net>
>>
>
> Intel recommends not using inc/dec.  Since these instructions don't update
> all of the flags, they cannot be issued in parallel to previous instructions
> that do.

That's true, but I think Icache misses will cost you more than
the false dependencies;  due to code size expansion in the
translation process, optimizing rules should not be obeyed
blindly.  I guess this should be measured.


Laurent

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Qemu-devel] Re: [Qemu-commits] [COMMIT a4b18c6] tcg/x86_64: generated dec/inc instead of sub/addwhen possible
  2009-09-28  8:21   ` Laurent Desnogues
@ 2009-09-29 15:51     ` Filip Navara
  2009-09-29 15:53       ` Laurent Desnogues
  0 siblings, 1 reply; 5+ messages in thread
From: Filip Navara @ 2009-09-29 15:51 UTC (permalink / raw)
  To: Laurent Desnogues; +Cc: Avi Kivity, Aurelien Jarno, qemu-devel@nongnu.org

On Mon, Sep 28, 2009 at 10:21 AM, Laurent Desnogues
<laurent.desnogues@gmail.com> wrote:
> On Mon, Sep 28, 2009 at 9:51 AM, Avi Kivity <avi@redhat.com> wrote:
>> On 09/27/2009 06:13 PM, Anthony Liguori wrote:
>>>
>>> From: Aurelien Jarno<aurelien@aurel32.net>
>>>
>>
>> Intel recommends not using inc/dec.  Since these instructions don't update
>> all of the flags, they cannot be issued in parallel to previous instructions
>> that do.
>
> That's true, but I think Icache misses will cost you more than
> the false dependencies;  due to code size expansion in the
> translation process, optimizing rules should not be obeyed
> blindly.  I guess this should be measured.

I vaguely remember measuring it and the results were different on
Pentium IV-based and Pentium M-based processors. On one of them
inc/dec was faster, while on the other it was add/sub. I can't
remember which one had which results though.

Best regards,
Filip Navara

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Qemu-devel] Re: [Qemu-commits] [COMMIT a4b18c6] tcg/x86_64: generated dec/inc instead of sub/addwhen possible
  2009-09-29 15:51     ` Filip Navara
@ 2009-09-29 15:53       ` Laurent Desnogues
  2009-09-29 15:55         ` Filip Navara
  0 siblings, 1 reply; 5+ messages in thread
From: Laurent Desnogues @ 2009-09-29 15:53 UTC (permalink / raw)
  To: Filip Navara; +Cc: Avi Kivity, Aurelien Jarno, qemu-devel@nongnu.org

On Tue, Sep 29, 2009 at 5:51 PM, Filip Navara <filip.navara@gmail.com> wrote:
>
> I vaguely remember measuring it and the results were different on
> Pentium IV-based and Pentium M-based processors. On one of them
> inc/dec was faster, while on the other it was add/sub. I can't
> remember which one had which results though.

Do you mean in a QEMU context or something else?  If that
was with QEMU, was the program significantly large?


Laurent

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Qemu-devel] Re: [Qemu-commits] [COMMIT a4b18c6] tcg/x86_64: generated dec/inc instead of sub/addwhen possible
  2009-09-29 15:53       ` Laurent Desnogues
@ 2009-09-29 15:55         ` Filip Navara
  0 siblings, 0 replies; 5+ messages in thread
From: Filip Navara @ 2009-09-29 15:55 UTC (permalink / raw)
  To: Laurent Desnogues; +Cc: Avi Kivity, Aurelien Jarno, qemu-devel@nongnu.org

On Tue, Sep 29, 2009 at 5:53 PM, Laurent Desnogues
<laurent.desnogues@gmail.com> wrote:
> On Tue, Sep 29, 2009 at 5:51 PM, Filip Navara <filip.navara@gmail.com> wrote:
>>
>> I vaguely remember measuring it and the results were different on
>> Pentium IV-based and Pentium M-based processors. On one of them
>> inc/dec was faster, while on the other it was add/sub. I can't
>> remember which one had which results though.
>
> Do you mean in a QEMU context or something else?  If that
> was with QEMU, was the program significantly large?

In QEMU/TCG context. It was some synthetic benchmark, most probably Dhrystone.

Best regards,
Filip Navara

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2009-09-29 16:46 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <200909271613.n8RGDCLo020606@d01av04.pok.ibm.com>
2009-09-28  7:51 ` [Qemu-devel] Re: [Qemu-commits] [COMMIT a4b18c6] tcg/x86_64: generated dec/inc instead of sub/addwhen possible Avi Kivity
2009-09-28  8:21   ` Laurent Desnogues
2009-09-29 15:51     ` Filip Navara
2009-09-29 15:53       ` Laurent Desnogues
2009-09-29 15:55         ` Filip Navara

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).