Re: [Qemu-devel] [RFC] [tcg] Idea on refactoring target code generation loop (gen_intermediate_code)

[Lluís Vilanova]

Claudio Fontana writes:

> Clearly late to the party,
> On 08.04.2016 22:14, Paolo Bonzini wrote:
>> 
>> On 08/04/2016 15:15, Markus Armbruster wrote:
>>>> On the other hand, minimal usage of templates instead of some of the
>>>> preprocessor gunk we have would be a very good thing IMNSHO.  I am
>>>> referring to the multiply included header files and to the macros with
>>>> type arguments (mostly QOM casts).
>>>> 
>>>> I don't think we need more C++ than that, but using templates as
>>>> basically a type-safe preprocessor would improve QEMU a little bit.
>>>> More rarely, lambdas could replace some preprocessor magic too, but
>>>> that's C11 and not many compilers support them.
>>>> 
>>>> But I won't weep if people say no because we have a lot other
>>>> low-hanging fruit to make QEMU better (especially the header file
>>> 
>>> "No!"  (Hey, you asked for it)
>>> 
>>> Back to serious.  As Peter Maydell said, "if we move away from C I'd
>>> rather it to be a language that's nicer than C rather than one that's
>>> uglier and larger and still retains all of C's flaws."
>> 
>> Sure, except that one plan is feasible now and can be done in small
>> steps; the other is not feasible now (for example Rust is not even
>> packaged in Fedora) and entails pretty much a rewrite of the whole code
>> base.

> I skip my personal take on these specific issue, but one very practical 
> concern I have with a potential move to C++,
> if I understand these proposals correctly, is with the speed of compilation 
> and the binary size, and also QEMU startup time.

> I noticed while developing for OSv that compilation with C++ and templates was
> very slow compared with C, so certain scripts around git I am using to build 
> and
> check code from scratch after each patch took a long time to complete.

> Do you know what these refactoring proposals' impact on compilation speed, 
> binary size and startup time would be?

For templates, binary size and startup time should be exactly the same (plus
whatever fixed costs C++ might have, if any at all). Compilation times really
depend on the complexity of the templates, but I think that a straight
conversion should not noticeably increase compilation times; the use of
templates that QEMU would have is pretty straightforward (not any complex
interrelation between different templated classes with their own templated
methods), and we'd be replacing the preprocessing of a file multiple times
(e.g., include softmmu_template.h 8 times) for templated functions in the
implementation file (no need to see templates on the headers).

In the case of objects, binary/memory size should be marginally lower with C++
(in some cases, the C++ compiler can elide the "parent_class" pointer that QEMU
adds on every object class). On startup time, I'm not aware of any costs added
by C++ objects, but I might be wrong (aren't vtable pointers prepared at
compilation time?). As for compilation time, I really don't know what important
effects classes can have.


Cheers,
  Lluis