[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Automatic generation of code-generator components (RETR
Re: [Qemu-devel] Automatic generation of code-generator components (RETRY)
Tue, 20 Jul 2010 20:29:13 -0400
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:22.214.171.124) Gecko/20100512 Thunderbird/3.0.5
On 7/20/2010 6:14 PM, Blue Swirl wrote:
If you keep the development process open, with patches, RFCs and other
proposals flowing regularly to upstream QEMU, I'd suppose the
developer community would welcome this. But there have been several
forks of QEMU and merging those looks hard. The problem with those was
that the development was kept behind a curtain until it was 'finished'
according to some internal standards and then it was presented to us
as something that should just be swallowed in whole. In the continuous
cooperation model the result will be seamless. It's also possible that
there's too much mismatch between the goals of the projects, but with
early involvement of both sides, it can be detected before it's too
Yes, I agree that an incremental and open process will work much
better. Obviously we'd need to learn the local customs :-) , but
I expect we'd start with one or two of the existing guests and
hosts, not replacing the current code but doing something like
using a different but related name. Among other things, we'd
probably want a scheme where we could test our code side by side
a known-working version at the start -- an interesting challenge,
but perhaps not too hard if we give it some thought. Anyway,
yes, it's important not to present something that is a huge change,
in one gulp, without experience-building and confidence-building
steps in the middle.
I think this case is interesting for the currently unimplemented
hosts, or if the performance is improved from existing hosts compared
to TCG. The extra optimization pass may waste time which will not be
gained back by faster execution time of the better generated code.
There's also KVM, which should be always the fastest for cases where
host and target CPUs match.
We can experiment some with different degrees of (simple)
optimization, though I expect TCG probably already chose
a sweet spot. I am not familiar yet with KVM and should
become more so. I gather that it is the case where guest
and host are the same, which indeed gives rise to both
unique opportunities and unique challenges in performance.
However, I remain confident that we can "encode" suitable
strategies with our tool.
You are right, though, that the most promise is for new
ISAs. We probably cannot do much better than TCG front-ends
and back-ends tuned by experts. However, the ease of
reworking various details may make it easier to tune and
possibly do a little better; certainly with new ISAs.
Again, current implementations basically consist of just a huge C
switch statement, so it's hard to improve performance from that.
Enabling new targets would be interesting though, or maybe one day an
automatically generated translator could beat a hand written one.
Again, thanks for your encouraging reply and your very
thoughtful and useful suggestions. I have been pleased to
find this a polite community -- sad that not all open
source communities are so polite and friendly!
Best wishes -- Eliot Moss