Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC

[Programmingkid <programmingkidx@gmail.com>]

> On Feb 25, 2020, at 7:09 AM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
> 
> On Mon, 24 Feb 2020, Programmingkid wrote:
>> Intel Core i5-2500S CPU @ 2.70GHz.
> [...]
>> Ok, I did test on the G4, here are my results:
>> 
>> Git commit: c1e667d2598b9b3ce62b8e89ed22dd38dfe9f57f
>> Mac OS 10.4.3 VM
>> -cpu G4
>> -USB audio device
>> 
>> Hardfloat=false
>> Audio sounds bad when playing midi file.
>> Extraction rate: 1.5x
>> Converting rate: 0.7x
>> Total time: 7:24
>> 
>> Hardfloat=true
>> Midi audio sounded perfect for about 30 seconds, then it went silent!
>> Extraction rate: 1.4x (slower with hard float)
>> Converting rate: 0.7x (same as without hardfloat)
>> Total time: 7:16 (faster time with hardfloat)
> 
> How is that extraction rate is slower but total time is less than without hardfloat? There must be other factors here than just FP ops. Maybe a better test is to not play the audio just save it to a file so other issues with USB is not influencing the test.

I does seem odd to me also. 

>> When I played sound this second time I hard the same broken audio I usually hear with the USB audio device with hardfloat set to false. When playing the same midi file with hardfloat set to true, the audio played perfectly! It only played for 30 seconds before it went silent.
> 
> So probably there are at least two problems: FPU emulation is not fast enough to decode audio to fill buffer then there's also something with usb-audio that jams it after a while? I don't think all of this is FPU related.

I think a timeout takes place and that is why audio stops playing. It is probably an USB OHCI issue. The other USB controller seems to work better. 

> 
>> I can give you the full testing suite if you like. I run it on Mac OS 10.4 but it should compile with gcc on Linux. I will send it to you in a separate email because it is big.
> 
> Thanks, I'll have a look and see if I can make sense of it but not sure when will I find time.

Please let me know if you have any questions with it.

> 
>> I have another idea on how to improve QEMU's performance. What if you enabled more CPUs for the PowerPC target? Mac OS 9, Mac OS X, and Linux support multiple CPUs. It might actually be easier to do this than to
> 
> Have you tried if it works? I think MTTCG is enabled for PPC64 but not sure about 32 bit PPC. The mac99 machine seems to init multiple CPUs but not sure if they'll use MTTCG. But you could test it to see if it makes any difference.

I had completely forgot about MTTCG. I think Howard once did some performance testing with it and came back with favorable results. Maybe this is another avenue we should look at.

> 
>> improve the FPU. I imagine the performance increase with multiple emulated CPUs would be much more noticeable.
> 
> The Amiga like OSes I'm interested in don't use multiple cores so I'm mainly interested in improving single core performance. Also I'm not sure if (part of) your problem is slow FPU preventing fast enough audio decoding then having multiple CPUs with slow FPU would help as this may use a single thread anyway.

Good point. MTTCG might be the option that really helps with speed improvements.