[Top][All Lists]

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

Re: [Qemu-devel] [PATCH for-1.5 0/9] Disable expensive QOM cast debuggin

From: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH for-1.5 0/9] Disable expensive QOM cast debugging for official releases
Date: Fri, 10 May 2013 21:00:19 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, May 10, 2013 at 12:41:07PM -0500, Anthony Liguori wrote:
> Paolo Bonzini <address@hidden> writes:
> > Il 10/05/2013 16:39, Anthony Liguori ha scritto:
> >> I just oppose the notion of disabling casts and *especially* only
> >> disabling casts for official builds.
> >
> > This actually happens all the time.  Exactly this kind of type-safe cast
> > is disabled in releases of GCC, but enabled when building from svn trunk.
> Let's assume for a moment that you are right and this behavior is what
> we should have.  Let's also assume there is a real regression here
> which has yet to have been established.

I have pointed out in another mail of this thread, that this type
checking account for about 9% of slowdown. Isn't that enough to say it's
a regression?

I still have to compare to 1.4, but it's not very fair, as a
significant work has been but on TCG to improve the performances,
especially on the target-ppc code.

I am currently preparing an image so that people can test that

> As soon as we open up 1.6 for development, we face an immediate
> regression in performance.  So we need to fix the real problem here
> anyway.
> I strongly suspect that if there is a problem, that optimizing
> leaf/concrete casts will take care of it.  Otherwise, a small lookup
> cache ought to do the trick too.  We can even use pointer comparisons
> for the lookup cache which should make it extremely cheap.
> Disabling casts doesn't give us a long term fix.  One of the solutions
> above does and patches also exist.

Why do you insist on using dynamic cast, on a hot path? It was using a
simple pointer before QOM in 1.4, it won't be less safe with if we use
a static cast instead of a dynamic one in 1.5.

With your arguments, we should drop all dataplane code, as it doesn't
use the QEMU core code. People should just not complain about the

Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net

reply via email to

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