AmigaOS 3.2 performance vs 3.1

[Firestone]

I've been doing some experiments with a few of my A1200s recently, and I'm searching for the best tuned installation of 3.2.2.1 for the following configuration:

Amiga 1200
Blizzard 1230IV/50Mhz
32MB Fastram
64GB Kingspec 2.5" PATA SSD

I got 3.2 installed on several Amigas, including ones with RTG, 060, Pistorms and Vampires, and they work great.
But the performance between 3.1 and 3.2 has annoyed me a bit since I installed it on the 030-setup. It's probably more noticeable there I guess.

OS3.2 is installed by using Blizkick to kick the 3.2 ROM first (3.0 is in ROM) , and this is the only modification to the system.

Everything works fine and stable, but there is a performance impact somewhere that I can't put my finger on. It's already noticeable after kicking 3.2 with Blizkick.
There will be a longer delay during boot which i think is by design allowing slow spin-up hard-drives to be detected, and probably some other SCSI-things are going on?

After clicking boot you can already feel that the system has lost some of it's performance. It will boot slower, just like the hard-drive access-speed got slowed down a bit after kicking 3.2
Actually, this feeling exists in 3.1.4 also.

But then there is the performance in Workbench doing normal things like application launching, opening several windows, text scrolling in the shell window is noticeable slower in these new systems.

In fact, booting with no startup-sequence and launching a game like Eye of The Beholder 2 (not WHD-loaded) feels much more sluggish if 3.2 is kicked compared if I just let the machine load 3.0 from ROM, or blizkicking 3.1. It's very noticeable if you move fast in the dungeon.

Is this intended, and does anyone else with the same setup experience these things?

Don't get me wrong, this is not meant criticism to anyone, I'm just curious from a technical perspective why and if there should be a difference.

[SpeedGeek]

There are several threads already posted here on EAB regarding these specific AmigaOS version slow-down issues. You might want to try a search for them.

IMO if you paid for these versions, than you certainly do have a right to criticize them, but it probably won't accomplish anything constructively.

[Cylon]

@Firestone
Your "can't put my finger on" and
"it feels like"
are not grounds someone can discuss objective speed benchmarks.

[pipper]

The most likely difference could be that you installed MMULibs as part of the 3.2 install. That can cost ~10% performance

[Thomas Richter]

Sigh. Stop speculating. There is an FAQ in 3.1.4 and 3.2 either. The issue is *most likely not* the MMU, but where the modules end up in RAM. Have you checked the FAQ?
Hint: The slowdown will most likely go away with a physical ROM, but even without a physical ROM, there are options. They are all listed in the FAQ.

[Thomas Richter]

Originally Posted by pipper

The most likely difference could be that you installed MMULibs as part of the 3.2 install. That can cost ~10% performance

...and would not explain anything related to 3.1.4. So: No.

[pipper]

He mentioned that he’s using Blizkick to use 3.2 roms. Shouldn’t that be as if true 3.2 roms are installed? The blizzard 1230 has maprom hardware independent of the MMU.

[patrik]

@Firestone: As Thomas mentioned, there will be a big performance hit if any modules end up in chip ram, like for example if the exec.library code is loaded in chip, it will have a significant impact.

Also the location of the library base of exec.library (library state, accessed a lot) has a significant impact on performance and general WB feel, but with the Blizzard, that should end up in chipmem disregarding OS version, so it should not affect your comparison. Unless you have fixed it with the 3.1-compatible LocalFast module in BlizKick, FastExec or tools from MMULib for one of the installs.

One detail here is that BlizKick and FastExec will not have any negative side-effect on the performance, but on the 030, MMULib will noticeable decrease the performance when it enables the MMU with the configuration it uses, see for example this thread.

I have written a tool, which is a work in progress, which will tell you which modules and library bases that are not in the fastest memory in an easy way:
Documentation: https://github.com/patrikaxelsson/ResidentSpeed
Executable: http://megaburken.net/~patrik/pt/ResidentSpeed

[Thomas Richter]

I afraid the memory location (it's address) is not an indication of the memory type a code sits in. This mistake has been done quite often, unfortunately, but it is no longer true with the MMU running.

[patrik]

Originally Posted by Thomas Richter

I afraid the memory location (it's address) is not an indication of the memory type a code sits in. This mistake has been done quite often, unfortunately, but it is no longer true with the MMU running.

That's why I test the read access speed of the location in ResidentSpeed.

This result is then compared it against the result of a read access speed test of a location in the highest priority memory. If they differ significantly, it is determined to be a performance issue.

[CCRider]

Originally Posted by patrik

I have written a tool, which is a work in progress, which will tell you which modules and library bases that are not in the fastest memory in an easy way:
Documentation: https://github.com/patrikaxelsson/ResidentSpeed
Executable: http://megaburken.net/~patrik/pt/ResidentSpeed

Just ran your tool here (A1200, TF1260, ROM 3.2.2 and MMULibs installed) and only expansion.library is on "slow speed".

Any ideas why?

[patrik]

Originally Posted by CCRider

Just ran your tool here (A1200, TF1260, ROM 3.2.2 and MMULibs installed) and only expansion.library is on "slow speed".

Any ideas why?

The library base of expansion.library is special as it is initialized first of all, before any fast memory is available, so it will always be allocated from chip.

However, expansion.library is not utilized frequently when you are using the system in general, so it is not an actual performance problem even if its library base is slow to access.

This is unfortunately not obvious from the output of ResidentSpeed, more like tribal knowledge(?) I do mention this in the documentation for ResidentSpeed, but I am sure it can be made more intuitive in some way?:

The results has to be valued by how much the components are used. For example anything related to exec.library should definately be as fast as possible, as that is the most used component of the system. On the other end we have expansion.library which is not used much, so it does not matter much where it is located.

[CCRider]

Originally Posted by patrik

The library base of expansion.library is special as it is initialized first of all, before any fast memory is available, so it will always be allocated from chip.

However, expansion.library is not utilized frequently when you are using the system in general, so it is not an actual performance problem even if its library base is slow to access.

This is unfortunately not obvious from the output of ResidentSpeed, more like tribal knowledge(?) I do mention this in the documentation for ResidentSpeed, but I am sure it can be made more intuitive in some way?:

More than explained, thanks!

I missed the README.md file on the first pass.

[Firestone]

Originally Posted by Thomas Richter

Sigh. Stop speculating. There is an FAQ in 3.1.4 and 3.2 either. The issue is *most likely not* the MMU, but where the modules end up in RAM. Have you checked the FAQ?
Hint: The slowdown will most likely go away with a physical ROM, but even without a physical ROM, there are options. They are all listed in the FAQ.

Yes i did actually read the FAQ, at least the parts where slowdown is mentioned and the options you have loading the rom modules.

But there are still some questions coming up, and one of them is why would there be a difference with physical ROMs on this when the kickstart is loaded with Blizkick?
Is something still executed directly from ROM regardless of this?

I don't think I have tried using MMU-libs in combination with "MuProtectModules ON REMAP" yet. I'll have do to some more tests.

[Firestone]

Originally Posted by Cylon

@Firestone
Your "can't put my finger on" and
"it feels like"
are not grounds someone can discuss objective speed benchmarks.

Yes I know that But the reason for posting is that I've found several threads about more or less the same subject, and this thread revealed some things I haven't seen before. Among them the ResidentSpeed-tool which might be helpful and giving us a clue on what's going on.

Of course I could have attached some benchmarks, but which benchmarks should it be? Sysspeed with intuitiontests ?

[Firestone]

Originally Posted by patrik

@Firestone: As Thomas mentioned, there will be a big performance hit if any modules end up in chip ram, like for example if the exec.library code is loaded in chip, it will have a significant impact.

Also the location of the library base of exec.library (library state, accessed a lot) has a significant impact on performance and general WB feel, but with the Blizzard, that should end up in chipmem disregarding OS version, so it should not affect your comparison. Unless you have fixed it with the 3.1-compatible LocalFast module in BlizKick, FastExec or tools from MMULib for one of the installs.

One detail here is that BlizKick and FastExec will not have any negative side-effect on the performance, but on the 030, MMULib will noticeable decrease the performance when it enables the MMU with the configuration it uses, see for example this thread.

I have written a tool, which is a work in progress, which will tell you which modules and library bases that are not in the fastest memory in an easy way:
Documentation: https://github.com/patrikaxelsson/ResidentSpeed
Executable: http://megaburken.net/~patrik/pt/ResidentSpeed

Thanks for all this detailed information. Helps a lot!

For reference, this is the result of ResidentSpeed for the system running OS3.2.2.1 :

Type     Name                    Version Size    Loc  Speed   Speed %
Region   interrupt vector table            1.00k Chip   6.25M    22.9
Region   system stack                      6.00k Chip   6.25M    23.0
LibBase  expansion.library        47.3       554 Chip   6.26M    22.8
LibBase  exec.library             47.10    1.50k Chip   6.25M    22.8
Resident intuition.library        47.52  110.68k Kick  26.35M    97.1
Resident romboot                  47.0       104 Kick  16.23M    50.0
Resident dos.library              47.30   35.16k Kick  26.54M    97.8

MMULibs is installed.
User-startup contains this line also:

SYS:MuTools/MuFastZero ON FastExec MoveSSP >NIL:

[Amiga68k]

Originally Posted by Firestone

User-startup contains this line also:

SYS:MuTools/MuFastZero ON FastExec MoveSSP >NIL:

When using BlizKick on my setup (060), I also need MuMove4K to get exec in Fast. Try adding that just after your BlizKick line, please also note this needs a second reboot.

I'm curious what that will do with the ResidentSpeed output.

[Firestone]

Here is a benchmark comparison between a plain installation of both systems.
Both Blizkicked (3.1 and 3.2) and using latest Sysspeed from Aminet to do the comparison.

Fast2Fast operations seems to stand out most where the 3.1 system wins by great margin.
Intuitiontests on the other hand seems to have slightly better results for some reason on 3.2.

Memory		3.2BK	3.1BK	Comparison
------		-----	-----	-----
Cache Read	31.36	31.53	1.01
ReadROMb	3.76	3.78	1.00
ReadROMw	7.23	7.26 	1.00
ReadROMl	13.30	13.35	1.00
ReadFastb	3.76	3.78	1.00
ReadFastw	7.23	7.27	1.00
ReadFastl	13.29	13.36	1.00
WriteFastb	4.95	4.97	1.00
WriteFastw	10.45	10.50	1.01
WriteFastl	23.51	23.62	1.00
Fast2Fastb	1.82	3.30	1.82
Fast2Fastw	3.61 	6.52 	1.80
Fast2Fastl	6.21	12.52 	2.02
Fast2Fastm	7.68	13.22	1.72
Fast2Fast16 -	-		-
ReadChipb	0.92	0.92	1.01
ReadChipw	1.85	1.86	1.01
ReadChipl	3.78	3.80	1.01
WriteChipb	1.70	1.71	1.00
WriteChipw	3.46	3.47	1.00
WriteChipl	6.79	6.82	1.00
Chip2Chipb	0.84	0.85	1.00
Chip2Chipw	1.70	1.71	1.00
Chip2Chipl	3.46	3.47	1.00
Chip2Chipm	3.08	3.09	1.00
Chip2Chip16 -		-		-
Fast2Chipb	0.92	0.92	1.01
Fast2Chipw	1.85	1.86	1.01
Fast2Chipl	3.78	3.80	1.01
Fast2Chipm	5.25 	5.28	1.00
Fast2Chip16	-		-		-

Intuition
---------
OpenWin16	10		10		1.00
OpenWin256	5 		5 		1.00
OpenWinHi	-		-		-
OpenWinTru	-		-		-
WinLayer16	12		7 		0.58
WinLayer256 5 		3 		0.60
WinLayerHi	-		-		-
WinLayerTru -		-		-
SizeWin16	66		64		0.97
SizeWin256	65		24		0.37
SizeWinHi	-		-		-
SizeWinTru	-		-		-
MoveWin16	127		34		0.27
MoveWin256	72		23		0.32
MoveWinHi	-		-		-
MoveWinTru	-		-		-
ConOutP16	42		38		0.90
ConOutP256	30		27 		0.90
ConOutPHi	-		-		-
ConOutPTru	-		-		-
OpenScr16	10		8 		0.80
OpenScr256	5 		5 		1.00
OpenScrHi	-		-		-
openScrTru	-		-		-
SwapScr16	50 		50		1.00
SwapScr256	50		50		1.00
SwapScrHi	-		-		-
SwapScrTru	-		-		-

Graphic
-------
ScrollX_16		8 	7 	0.88
ScrollX_256		3 	2 	0.67
ScrollX_Hi 		-	-	-
ScrollX_Tru 	-	-	-
ScrollY_16		8 	7 	0.88
ScrollY_256 	3 	2 	0.67
ScrollY_Hi		-	-	-
ScrollY_Tru		-	-	-
PrintTxt16		709	691	0.97
PrintTxt256		332	301	0.91
PrintTxtHi		-	-	-
PrintTxtTru		-	-	-
RectFill16		475	459	0.97
RectFill256		187	167	0.89
RectFillHi		-	-	-
RectFillTru		-	-	-
DrwElpse16		229	226	0.99
DrwElpse256		126	118	0.94
DrwElpseHi		-	-	-
DrwElpseTru		-	-	-
DrwCircle16		219	216	0.99
DrwCricle256	120	113	0.94
DrwCircleHi		-	-	-
DrwCircleTru	-	-	-
WrtPixel16		24834	26482	1.07
WrtPixel256		16387	16571	1.01
WrtPixelHi		-		-		-
WrtPixelTru		-		-		-
HorLines16		278		253		0.91
HorLines256		106		691		0.86
HorLinesHi		-		-		-
HirLinesTru		-		-		-
VerLines16		353		308		0.87
VerLines256		134		109		0.81
VerLinesHi		-		-		-
VerLinesTru		-		-		-
DiaLines16		312		280		0.90
DiaLines256		134		109		0.81
DiaLinesHi		-		-		-
DiaLinesTru		-		-		-
AreaElps16		135		134		0.99
AreaElps256		91 		85		0.93
AreaElpsHi		-		-		-
AreaElpsTru		-		-		-
AreaCir16		126		125		0.99
AreaCir256		82 		77		0.94
AreaCirHi		-		-		-
AreaCirTru		-		-		-
AreaFill16		187 	180		0.96
AreaFill256		91 		81		0.89
AreaFillHi		-		-		-
AreaFillTru		-		-		-

CPU/FPU
-------
MIPS			16.44	16.53 	1.00
MFLOPS			1.11 	1.11 	1.00

[patrik]

Originally Posted by Firestone

Thanks for all this detailed information. Helps a lot!

For reference, this is the result of ResidentSpeed for the system running OS3.2.2.1 :

Type     Name                    Version Size    Loc  Speed   Speed %
Region   interrupt vector table            1.00k Chip   6.25M    22.9
Region   system stack                      6.00k Chip   6.25M    23.0
LibBase  expansion.library        47.3       554 Chip   6.26M    22.8
LibBase  exec.library             47.10    1.50k Chip   6.25M    22.8
Resident intuition.library        47.52  110.68k Kick  26.35M    97.1
Resident romboot                  47.0       104 Kick  16.23M    50.0
Resident dos.library              47.30   35.16k Kick  26.54M    97.8

You can ignore intuition.library, dos.library, I am obviously allowing too small performance discrepancy to show up as a performance issue - it might not be the same the next time you run it. Also romboot is so tiny, it might give flaky speed results.

The important component in the above result is the library base for exec.library, which will affect the performance a lot. The system stack, way less. However, unless you are running any patches for your 3.1 system, both the library base for exec.library and system stack should reports slow results with ResidentSpeed.

Originally Posted by Firestone

MMULibs is installed.
User-startup contains this line also:

SYS:MuTools/MuFastZero ON FastExec MoveSSP >NIL:

Given the above ResidentSpeed output, this above MuFastZero line does not seem to work, but the solution should be what Amiga68k said.

Originally Posted by Firestone

Yes i did actually read the FAQ, at least the parts where slowdown is mentioned and the options you have loading the rom modules.

But there are still some questions coming up, and one of them is why would there be a difference with physical ROMs on this when the kickstart is loaded with Blizkick?
Is something still executed directly from ROM regardless of this?

There should be no difference in general performance, unless there is a difference in patches or say one system has MMULib and the other does not.

Originally Posted by Firestone

Here is a benchmark comparison between a plain installation of both systems.
Both Blizkicked (3.1 and 3.2) and using latest Sysspeed from Aminet to do the comparison.

Fast2Fast operations seems to stand out most where the 3.1 system wins by great margin.
Intuitiontests on the other hand seems to have slightly better results for some reason on 3.2.

Memory		3.2BK	3.1BK	Comparison
...
Fast2Fastb	1.82	3.30	1.82
Fast2Fastw	3.61 	6.52 	1.80
Fast2Fastl	6.21	12.52 	2.02
Fast2Fastm	7.68	13.22	1.72
Fast2Fast16 -	-		-
...

Does the results from ResidentSpeed look the same for both systems? Also, if 3.1 does not have MMULib installed, remove 68030.library and mmu.library from the 3.2 system and re-run the tests.

[DanyPPC]

Is it possible to use MuMove4K as a BlizKick Module avoiding a second reboot ?

I see a MuMove4K module on Blizkick archive, but I don't know if it's obsoleted.


EDIT: for me the old MuMove4K BK module works, exec is moved in fast, the system runs better and the IDE speed get 2,0 MB/s vs 1,5MB/s. And only one Reboot !