Aurelien Jarno <aurel...@aurel32.net> writes: > On Fri, May 10, 2013 at 12:41:07PM -0500, Anthony Liguori wrote: >> Paolo Bonzini <pbonz...@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 > aurel...@aurel32.net http://www.aurel32.net