[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: BALATON Zoltan
Subject: Re: [PATCH 0/5] tcg: Dynamically allocate temporaries
Date: Wed, 20 Jan 2021 10:03:40 +0100 (CET)
User-agent: Alpine 2.03 (LMD 1266 2009-07-14)

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:


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.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]