Does Kickstart 3.1 lower processing performance by 3%?

[Photon]

It was hard to find the right forum for this question!

On real hardware and in WinUAE, in SysInfo 3.24, an A500 gets a score of 1.03 vs A600 with Kickstart 1.3, and a score of 1.00 vs A600 with Kickstart 3.1 (1.00 being the result you'd expect originally, but there it is, 1.03 and SysInfo 3.24 was made before Kickstart 3.1) .

It's likely that 3.1 does more than 1.3, and that the benefit leaves less processing time for applications,. That it happens to be 1.00 on Kickstart 3.1 on real hardware is likely just a number; pure coincidence.

Out of curiosity I'd like to ask those who write OS applications who have had to deal with performance if they've noticed this and what it may be due to specifically.

And if it is due to 3.1, what would I turn off, if I would like my OS application to perform maximally without completely turning off the OS as is done in demos and games.

[dodke]

On my a600 without the Furia I did notice that some effects didn't run in one frame anymore if I had a CF adapter plugged in the PCMCIA. So that definitely seems to eat a fairly constant amount of CPU. Maybe HDs could also have a small impact?

[Photon]

Well SysInfo doesn't load anything during speed measurement and there was no PCMCIA involved here - and A600 is just a datapoint measured by Mr. Wilson to compare the other Amigas to. (You know, the list A600, A2000 33% fast cos of real fastmem, A3000 25 Mhz, and so on.)

The expectation would be that all things equal, an A500 with chip+slowmem would perform exactly like A600 with only chipmem - no matter how the benchmark is written, really. I.e. 1.00, not 1.03.

But with the only thing changed, Kickstart version, the same hardware configuration reports different results for the same benchmark being run.

I don't know what's more baffling, the 1.03 score for KS13 or the difference from just switching KS version. I'd expect SysInfo to turn off interrupts with Exec, but if so that makes it even harder to pinpoint what it is

[Retro1234]

what about Kicks in-between? like 3.0 etc

[Thomas Richter]

Originally Posted by Photon

Out of curiosity I'd like to ask those who write OS applications who have had to deal with performance if they've noticed this and what it may be due to specifically.

And if it is due to 3.1, what would I turn off, if I would like my OS application to perform maximally without completely turning off the OS as is done in demos and games.

As if 3% would make any difference... The 3% come likely from more processing by the input.device, or in particular the intuition input handler, and the commodities input handler if you have any commodities installed.

[Photon]

Originally Posted by Retro1234

what about Kicks in-between? like 3.0 etc

1.3 and 3.1 are selected wisely - all old Amigas can upgrade to 1.3 and benefit, all Amigas can upgrade to 3.1 to run the latest Workbench. So for this thread, I'm keeping focus only on these two to reduce the number of test cases, data, and what-ifs.

Originally Posted by Thomas Richter

As if 3% would make any difference... The 3% come likely from more processing by the input.device, or in particular the intuition input handler, and the commodities input handler if you have any commodities installed.

I'm just curious about the difference.

Since interrupts seem disabled (no mouse input is detected or handled during the test), and SysInfo doesn't use a normal screen where perhaps the copper list could be much more complex in 3.1, and I start it from a clean boot to CLI and Workbench isn't running, this makes it even more curious.

Harddisk is also eliminated since I get the same result for 1.3 doing the same clean boot to CLI.

It could be that the A600 was measured under Kick 2.0, and it's 3% slower just like 3.1, but if so that still leaves Kick 1.3 3% faster than both of them, so it doesn't explain it.

It could be that SysInfo version 3.24 is new enough to handle 3.1 (or > 1.3) differently from 1.3. Perhaps some interrupt or DMA channel must be left on or is left on differently by each Kickstart when calling Exec Disable() or similar, if that is what is used before running the benchmark.

More likely than the program handling it differently, is that the interrupt mask is set differently by the two Kickstarts, when the same Kickstart function is called.

[Retro1234]

I understand but what if what you propose only happens exclusively on 3.1 and not any other kickstart I think this would be interesting.

[BastyCDGS]

Originally Posted by Photon

Since interrupts seem disabled (no mouse input is detected or handled during the test), and SysInfo doesn't use a normal screen where perhaps the copper list could be much more complex in 3.1, and I start it from a clean boot to CLI and Workbench isn't running, this makes it even more curious.

Did you check that SysInfo really disables interrupts and not just multitasking with Forbid()?

If I remember correctly, the Amiga SDK warns about disabling interrupts for too long and since the speed tests of SysInfo require some few seconds, they could have decided to just disable multitasking instead of interrupts per Disable() for safety reasons.

This could explain the difference: It is caused by the PCMCIA interrupt handler (which isn't initialized by KS1.3) to handle the hardware.

Did you compare with A500+? It has KS2.0 by default and also 1 MB chip but no PCMCIA.

Another possibility could be ECS vs. OCS. But I'm not sure if ECS is faster in some small aspects than OCS.

EDIT: Difference could also caused by the internal IDE controller interrupt handling.

[Geijer]

SysInfo uses Forbid/Permit

Here is a small snippet from 3.24:

			movea.l	4.w,a6
			jsr	(_LVOForbid,a6)
			bsr	sub_CalcChipReadSpeed
			move.l	4.w,a6
			jsr	(_LVOPermit,a6)

Unfortunantely the "Chip Speed vs A600" is implemented in a not that good way. There is too many instructions run compared to how much data is read from CHIP mem to make the test relevant. If you compare the result with and witout "real" FAST mem you will see quite a big difference in speed. But in reality the CHIP speed is exactly the same.

In the latest, yet to be released, SysInfo I've replaced the "Chip Speed vs A600" with a "bus test" implementation and print the result in MB/s instead.

[Bruce Abbott]

Originally Posted by Geijer

SysInfo uses Forbid/Permit

Here is a small snippet from 3.24:

			movea.l	4.w,a6
			jsr	(_LVOForbid,a6)
			bsr	sub_CalcChipReadSpeed
			move.l	4.w,a6
			jsr	(_LVOPermit,a6)

Unfortunantely the "Chip Speed vs A600" is implemented in a not that good way. There is too many instructions run compared to how much data is read from CHIP mem to make the test relevant. If you compare the result with and witout "real" FAST mem you will see quite a big difference in speed. But in reality the CHIP speed is exactly the same.

In the latest, yet to be released, SysInfo I've replaced the "Chip Speed vs A600" with a "bus test" implementation and print the result in MB/s instead.

You can't trust a benchmark program if you don't know what code is in it. AIBB's 'write pixel' test is 3 times slower on my A1200 when the Enforcer is running, due to it accessing low memory unnecessarily. Execbase should be cached in a variable, not loaded from location 4 each time you need it!

[Photon]

Originally Posted by Geijer

SysInfo uses Forbid/Permit

Here is a small snippet from 3.24:

			movea.l	4.w,a6
			jsr	(_LVOForbid,a6)
			bsr	sub_CalcChipReadSpeed
			move.l	4.w,a6
			jsr	(_LVOPermit,a6)

Unfortunantely the "Chip Speed vs A600" is implemented in a not that good way. There is too many instructions run compared to how much data is read from CHIP mem to make the test relevant. If you compare the result with and witout "real" FAST mem you will see quite a big difference in speed. But in reality the CHIP speed is exactly the same.

In the latest, yet to be released, SysInfo I've replaced the "Chip Speed vs A600" with a "bus test" implementation and print the result in MB/s instead.

I take this to mean that there are extra, or more time-consuming, interrupts running on 3.1 that are not part of the multitasking interrupts. Either that, or Forbid() forbids less on 3.1 than 1.3.

A benchmark is a benchmark regardless of whether it's written as closely to test the hardware as possible / as far from testing the OS as possible. I.e. it can be as crap as you like, and it still gives a score relative to other rigs.

Now, if exactly the same code is running, there can be no difference between two machines with the same CPU and chipset DMA load on the CPU.

So the 1.03 score may be up to the A600 score measured running a different kickstart version that is slower because of my first paragraph. That kickstart ran different code.

Regarding MB/s, it's actually even more controversial than just a score, because you'd have to prove the code is performance perfect or you're partly measuring the speed of the code!

But it would be neat if the new version fixes some obvious bad things.