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? 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. > 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 performance. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
