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

[Programmingkid]

> On Feb 25, 2020, at 7:09 AM, BALATON Zoltan <address@hidden> 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.