Re: [Qemu-ppc] MorphOS benchmark results

[BALATON Zoltan]

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:
> > https://www.slideshare.net/linaroorg/hkg18tr08-upstreaming-sve-in-qemu-92876219

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.

Regards,
BALATON Zoltan