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

[Anthony Liguori <aliguori@us.ibm.com>]

Aurelien Jarno <aurelien@aurel32.net> writes:

> On Fri, May 10, 2013 at 12:41:07PM -0500, Anthony Liguori wrote:
>> Paolo Bonzini <pbonzini@redhat.com> 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?

Yes, it's a regression.  I hadn't seen your note when I wrote the above.

I believe http://article.gmane.org/gmane.comp.emulators.qemu/210976
fixes the problem without eliminating any checking.

> 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
> themselves.

I can reproduce large numbers of casts FWIW so no need to on my end.
I've confirmed the above patch fixes it.

>> 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's a question of safety.

> 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.

The patch I posted should make it equally fast.

> 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
> performance.

No one is complaining about performance.

I merely stated that if performance is a problem, give us a chance to
fix it before completely disabling a feature.

And indeed, now I have a fix that doesn't disable anything.

Regards,

Anthony Liguori

>
> -- 
> Aurelien Jarno                          GPG: 1024D/F1BCDB73
> aurelien@aurel32.net                 http://www.aurel32.net