[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH experiment 00/16] C++20 coroutine backend
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [PATCH experiment 00/16] C++20 coroutine backend |
Date: |
Thu, 17 Mar 2022 12:16:25 +0000 |
User-agent: |
Mutt/2.1.5 (2021-12-30) |
* Paolo Bonzini (pbonzini@redhat.com) wrote:
> On 3/15/22 16:55, Daniel P. Berrangé wrote:
> > Expecting maintainers to enforce a subset during code review feels
> > like it would be a tedious burden, that will inevitably let stuff
> > through because humans are fallible, especially when presented
> > with uninspiring, tedious, repetitive tasks.
> >
> > Restricting ourselves to a subset is only viable if we have
> > an automated tool that can reliably enforce that subset. I'm not
> > sure that any such tool exists, and not convinced our time is
> > best served by trying to write & maintainer one either.
>
> We don't need to have a policy on which features are used. We need to have
> goals for what to use C++ for. I won't go into further details here,
> because I had already posted "When and how to use C++"[1] about an hour
> before your reply.
>
> > IOW, I fear one we allow C++ in any level, it won't be practical
> > to constrain it as much we desire. I fear us turning QEMU into
> > even more of a monster like other big C++ apps I see which take
> > all hours to compile while using all available RAM in Fedora RPM
> > build hosts.
>
> Sorry but this is FUD. There's plenty of C++ apps and libraries that do not
> "take hours to compile while using all available RAM". You're probably
> thinking of the Chromium/Firefox/Libreoffice triplet but those are an order
> of magnitude larger than QEMU. And in fact, QEMU is *already* a monster
> that takes longer to compile than most other packages, no matter the
> language they're written in.
>
> Most of KDE and everything that uses Qt is written in C++, and so is
> Inkscape in GTK+ land. LLVM and Clang are written in C++. Hotspot and V8
> are written in C++. Kodi, MAME and DolphinEmu are written in C++. GCC and
> GDB have migrated to C++ and their compile times have not exploded.
While I think it does take longer to compile, the bigger problem for
the CI setup is the amount of RAM-per-compile-process; it's not so much
the fact that those applications are huge that's the problem, it's that
a make -j ($threads) can run out of RAM.
Dave
> > My other question is whether adoption of C++ would complicate any
> > desire to make more use of Rust in QEMU ? I know Rust came out of
> > work by the Mozilla Firefox crew, and Firefox was C++, but I don't
> > have any idea how they integrated use of Rust with Firefox, so
> > whether there are any gotcha's for us or not ?
>
> Any Rust integration would go through C APIs. Using Rust in the block layer
> would certainly be much harder, though perhaps not impossible, if the block
> layer uses C++ coroutines. Rust supports something similar, but
> two-direction interoperability would be hard.
>
> For everything else, not much. Even if using C++, the fact that QEMU's APIs
> are primarily C would not change. Changing "timer_mod_ns(timer, ns)" to
> "timer.modify_ns(ns)" is not on the table.
>
> But really, first of all the question should be who is doing work on
> integrating Rust with QEMU. I typically hear about this topic exactly once
> a year at KVM Forum, and then nothing. We have seen Marc-André's QAPI
> integration experiment, but it's not clear to me what the path would be from
> there to wider use in QEMU.
>
> In particular, after ~3 years of talking about it, it is not even clear:
>
> - what subsystems would benefit the most from the adoption of Rust, and
> whether that would be feasible without a rewrite which will simply never
> happen
>
> - what the plans would be for coexistence of Rust and C code within a
> subsystem
>
> - whether maintainers would be on board with adopting a completely different
> language, and who in the community has enough Rust experience to shepherd us
> through the learning experience
>
> The first two questions have answers in the other message if s/Rust/C++/,
> and as to the last I think we're already further in the discussion.
>
> Thanks,
>
> Paolo
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
- Re: [PATCH experiment 00/16] C++20 coroutine backend, (continued)
- Re: [PATCH experiment 00/16] C++20 coroutine backend, Kevin Wolf, 2022/03/15
- Re: [PATCH experiment 00/16] C++20 coroutine backend, Stefan Hajnoczi, 2022/03/15
- Re: [PATCH experiment 00/16] C++20 coroutine backend, Daniel P . Berrangé, 2022/03/15
- Re: [PATCH experiment 00/16] C++20 coroutine backend, Paolo Bonzini, 2022/03/15
- Re: [PATCH experiment 00/16] C++20 coroutine backend, Stefan Hajnoczi, 2022/03/16
- Re: [PATCH experiment 00/16] C++20 coroutine backend, Kevin Wolf, 2022/03/16
- Re: [PATCH experiment 00/16] C++20 coroutine backend,
Dr. David Alan Gilbert <=
- Re: [PATCH experiment 00/16] C++20 coroutine backend, Daniel P . Berrangé, 2022/03/17
- Re: [PATCH experiment 00/16] C++20 coroutine backend, Markus Armbruster, 2022/03/31
- When and how to use C++ (was Re: [PATCH experiment 00/16] C++20 coroutine backend), Paolo Bonzini, 2022/03/15
Re: [PATCH experiment 00/16] C++20 coroutine backend, Daniel P . Berrangé, 2022/03/14
Re: [PATCH experiment 00/16] C++20 coroutine backend, Daniel P . Berrangé, 2022/03/15