Re: [PATCH 0/5] tcg: Dynamically allocate temporaries

[BALATON Zoltan <balaton@eik.bme.hu>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4061 bytes --]

On Wed, 20 Jan 2021, Philippe Mathieu-Daudé wrote:
> On 1/20/21 12:06 AM, BALATON Zoltan wrote:
>> On Tue, 19 Jan 2021, Richard Henderson wrote:
>>> My recent change for caching tcg constants has, in a number of cases,
>>> overflowed the statically allocated array of temporaries.  Change to
>>> dynamic allocation.
>>
>> This seems to work for me so
>>
>> Tested-by: BALATON Zoltan <balaton@eik.bme.hu>
>>
>> but have you done any performance tests to check that this actually
>> improves emulation speed? To mee it seems slower. Booting AmigaOS on
>> sam460ex with c0dd6654f207 (just before your TCG series) takes:
>>
>> real    0m33.829s
>> user    0m34.432s
>> sys    0m0.296s
>>
>> but on HEAD with this series:
>>
>> real    0m44.381s
>> user    0m46.058s
>> sys    0m0.532s
>>
>> This is noticable decrease in speed also without measuring it. With just
>> increasing the TCG_MAX_TEMPS to 2048 on 7c79721606be without this series
>> I get:
>>
>> real    0m42.681s
>> user    0m44.208s
>> sys    0m0.435s
>>
>> So the performance regression is somewhere in the original series not in
>> this fix up series.
>
> Cc'ing Lukas for the performance part, as he is investigating
> how to catch such regressions.

I think there was a GSoC last year that resulted in some scripts to do 
performance testing and even bisecting regressions. I've seen a few 
reports posted about those but maybe the project should also use the 
results and run these on some dedicated test machines regularly to be 
useful. The GSoC has ended, so the student has left and I think the mentor 
was Aleksandar M. who may also be doing something else now so these 
benchmarking scripts seem to be abandoned. But maybe could be picked up as 
a starting point or inspiration for any similar activity to build on those 
results.

>>> I'll note that nothing in check-acceptance triggers this overflow.
>>> Anyone care to add some more test cases there?
>>
>> The proposed test for the upcoming pegasos2 machine may also catch this
>> (when that will be merged, its dependencies are still under review)
>
> What are your running on pegasos2?

I've sent you before what test I think we could do for pegasos2, see:

https://lists.nongnu.org/archive/html/qemu-ppc/2021-01/msg00112.html

but I could not write the script for that and have no way to test it so 
some help would be needed with that. By the way, before that there are 
also the vt82c686 patches still waiting for review. I hope you haven't 
forgot and will eventually come back to them.

>> or
>> the sam460ex test that currently only checks the firmware could be
>> enhanced to try to boot AROS if somebody wants to do that. The drawback
>> is that it needs an external iso whereas the current test doesn't need
>> any additional images but it did not catch problems with IRQ and neither
>> this problem with TCG temps.
>
> So this other option is not very useful, right?

It's still useful to test if the machine is working at all but the 
firmware does not seem to use interrupts and if you don't boot anything it 
won't access disks so some parts will not be tested by only firmware level 
testing. Basically only CPU, RAM, ROM, serial would be tested and that the 
machine could be created which would still catch some bugs but IRQs and 
IDE probably would only be tested by trying to boot an OS. I think Guenter 
runs Linux kernel boot tests but with -kernel option so disks would still 
not be tested by that therefore it may be more useful to run some other OS 
booted from CD just to increase coverage. Since I plan to use MorphOS for 
pegasos2 as test, sam460ex could use AROS (AmigaOS is not freely available 
so that cannot be used but I also test with that). The AROS isos are free 
but may be somewhat unstable so instead of using the latest, one should 
use a known working version and only update after manual testing, 
otherwise the test may break due to change in AROS.

Regards,
BALATON Zoltan