[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] MorphOS benchmark results

From: BALATON Zoltan
Subject: Re: [Qemu-ppc] MorphOS benchmark results
Date: Wed, 18 Jul 2018 19:11:17 +0200 (CEST)
User-agent: Alpine 2.21 (BSF 202 2017-01-01)

On Wed, 18 Jul 2018, Programmingkid wrote:
On Jul 18, 2018, at 9:53 AM, BALATON Zoltan <address@hidden> wrote: So if you run anything that mainly depend on these then the performance you get will be much less than would be desirable. So these could be improved and fortunately there was some work done for ARM emulation already to address these which were merged recently. These may be used as a foundation or to give an idea what would be needed on the PPC side to leverage these results. Tha Altivec side may only need using the inftastructure put in for ARM and x86 also from PPC emulation, the floating point issues may be a bit more difficult due to above described problems but maybe using hardware support for some common operations with only a few edge cases only, leaving the more complex things go via softmmu could be done more easily and could already get

I was writing this too fast and made a lot of typos. I've of course meant softfloat but hope it made sense nevertheless.

some improvement. (This was also tried before but not finished yet so if anyone wants to pick up I think they could.)

I've found this excelent talk by Alex Bennée summarising everything that was 
recently done in this area and also has a quick intro on how to contribute to 
QEMU so it is highly recommended for anyone who has the ability and willingness 
to improve these watch this and follow links in the presentation to get started:

There were some experiments and unfunished patches mentioned in this talk to use hardware float for some less problematic cases. I've meant that someone could try those and see if it could be done for PPC too. I haven't looked at it and don't have time to do it or learn about details of IEEE floating point and its PPC implementation but maybe someone who already knows that or willing to learn could use this info.

Speeding up the floating point unit in QEMU is going to be a challenge. I think our only hope right now it to improve the MTTCG.

AFAIU MTTCG only helps with SMP emulation so this is not interesting for Amiga like systems and I don't see how could it help floating point or Altivec workloads. Maybe something else that would use additional host CPUs to precompute TBs (kind of like speculative execution) could be concieved (may make a nice reseach project) but maybe it's too complex to be practical compared to improving floating point and vector instructions which is more in the interest of other architectures as well that would probably use additional host CPUs to emulate more guest cores as in MTTCG.

Right now I am working on fixing the floating point status and control register. The flags that make it up are not all correctly set. Hopefully this will improve things for PPC guests.

This would improve accuracy but probably not speed (unless you also manage to do some optimisations along the way). Nevertheless it is greatly appreciated just like any improvement to PPC emulation in QEMU. Keep up the good work.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]