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