Performance patches for Amiga OS 3.2?

[shelter]

Originally Posted by mfilos

[*]NoMoreDiv0 (stops "Division by Zero" app crashes)

Seems like it's only needed when the CPU is very fast, like JIT in WinUAE or maybe when running PiStorm?

Originally Posted by mfilos

[*]ScreenTime for having date/time in titlebar and click-on calendar[/list]

I like that, neat little addon for the workbench.

Regarding PoolMem, I think THOR said it wasn't needed in OS 3.2.x.

[Thomas Richter]

If you are loading modules with LoadModule, these will typically already end up in the fastest memory - if that memory survives a reset. MuFastROM only places the ROM components in RAM, but not those coming from LoadModule. What you can do is to use MuProtectModules to prevent them from getting overwritten.

BlazeWCP should not provide a significant improvement anymore, at least not as significant as under 3.1. The graphics.library chunky to planar conversion functions became a lot faster with 3.1.4 already.

I still wonder where FBlit is faster than P96. P96 improved its low-level functions also over the last versions, including FillRect and BltBitMap.

What you can try is MuFastZero *if* your system does not provide autoconfiguring fast RAM. This will move exec (and expansion) to the fastest RAM available. Again, this does not hold if fast ram is autoconfiguring as then exec will relocate itself to this ram already as soon as expansion got its chance to integrate the RAM.

[shelter]

Originally Posted by Thomas Richter

If you are loading modules with LoadModule, these will typically already end up in the fastest memory - if that memory survives a reset. MuFastROM only places the ROM components in RAM, but not those coming from LoadModule. What you can do is to use MuProtectModules to prevent them from getting overwritten.

BlazeWCP should not provide a significant improvement anymore, at least not as significant as under 3.1. The graphics.library chunky to planar conversion functions became a lot faster with 3.1.4 already.

I still wonder where FBlit is faster than P96. P96 improved its low-level functions also over the last versions, including FillRect and BltBitMap.

What you can try is MuFastZero *if* your system does not provide autoconfiguring fast RAM. This will move exec (and expansion) to the fastest RAM available. Again, this does not hold if fast ram is autoconfiguring as then exec will relocate itself to this ram already as soon as expansion got its chance to integrate the RAM.

I found that running:

MuMove4k A1200 PrepareEmul
MuFastROM ON PROTECT
MuFastZero ON FASTEXEC MOVESSP

... does seem to improve things slightly on a TF1230 system. How on earth do I know this?
Well... I am no expert but SysInfo gives better results, ResidentSpeed gives good results and checking with Scout everyhing seems to be located in Fast RAM, except for the expansion.library of course.

Maybe we were bashing Native/P96 a bit too hard. They are similar but I feel like Workbench usage feels snappier when using FBlit. Maybe it's because P96 doesn't patch text which is very apparent in some SysSpeed tests and you also notice it when using applications, like TextEdit or ATC for example.

[shelter]

[removed by OP]

[shelter]

Perhaps not a fair comparison but it seems like Text output is waaaaaaaaay faster in ClassicWB (OS3.1) with FBlit/FText enabled than BestClassicWB in OS3.2 for some reason.

Overall ClassicWB (OS3.1) seems faster, at least in most SysSpeed benchmarks.
So I'm not sure what sort of Voodoo ClassicWB got going. I expected OS3.1 to be much slower.

[Thomas Richter]

A typical voodoo is that LoadModule places your modules into the only MEMF_KICK-able memory, which is chip mem, and hence slow. The NOMEMFKICK option of LoadModule may help on some boards.

[shelter]

Originally Posted by Thomas Richter

A typical voodoo is that LoadModule places your modules into the only MEMF_KICK-able memory, which is chip mem, and hence slow. The NOMEMFKICK option of LoadModule may help on some boards.

I have to compare where they are located.

The AIBB TG test is faster in OS 3.1 too, so it isn't just SysSpeed.

It's either what you said or FText isn't as good as in OS3.1. Or text output is just generally slower in OS3.2.x for some reason. Unfortunately I think it's the latter. Because I get 100% on everything now with Patrick's ResidentSpeed test. Also looking in Scout everything seems to be in fast ram.

[shelter]

@THOR
I figured it out, P96 installs a Generic Monitor in Devs:Monitors, that file messes up the FBlit/FText patching somehow making it slower. It was that single Generic monitor all along (I didn't have it in my OS3.1 install which is why that was faster)

So the conclusion is, FText is NOT slower in OS3.2, it's basically on par with OS3.1 Even without FText.
And overall the performance is better in OS3.2.

[Thomas Richter]

Please do not mix FBilt with P96. This will create an entire mess of the system.

[shelter]

Yes, I know. I wasn't aware of the Generic Monitor being installed, it happend during an update of P96. The Generic monitor triggered the loading of the P96 drivers which caused a mess, like you said.
I always disable FBlit when I try the Native driver but I didn't know about the Generic driver.

[Thomas Richter]

I made a couple of tests here, and applied a couple of modifications of the blitter emulation on my A1200 with a Blizzard 1230. On this particular machine, the native blitter is still faster than the CPU on "simple enough" operations such as moving a bitmap or blitting a bitmap without a mask. The problem is really the bandwidth between the CPU and the chip memory.

While I do not know how FBlit works, P96 performs every blit through the CPU if "DisableAmigaBlitter" is set. If it is not set, but "PlanesToFast" is set, then P96 will only blit those bitplanes through the CPU which are not in chip memory. As it seems, this configuration is faster on some machines.

Note that you need to re-set these environment variables *after* Native has been loaded as it alters both variables.

[shelter]

So for testing this, setting the env in AmigaShell like this is enough?
SetEnv Picasso96/DisableAmigaBlitter No
SetEnv Picasso96/PlanesToFast Yes

Nothing else is needed? (what I mean is, no "reload" of rtg.library?)

EDIT:
I tried some more, no matter what I set, FBlit/FText is twice as fast in some tests than P96/Native.
Some examples, the ScrollX_16, PrintTXt16, ConOutP16 tests, to name a few.
I guess that's why people hang on to using FBlit, the possible issues it creates is still worth the performance boost that it gives.

[No.3]

Originally Posted by Thomas Richter

While I do not know how FBlit works

if you are bored, the FBlit source code is available: http://aminet.net/package/util/boot/fblit_source

[shelter]

With OS 3.2.2 it doesn't seem like ramlib have to be included in the prefs for Executive anymore.
I will update the first post if anyone else can verify this too.

[ugrnm]

Thanks for starting this thread and maintaining/testing this list of patches, I find it very useful for people like myself who only started to use an Amiga recently!

I'm trying to make use of TRSaferPtch and while it seems to work fine, I cannot manage to get the function names displayed. I have edited the tooltype of ShowPatch with the following:

(FDDIR=DH1:vault/system/amigaos/AmigaOS-3.2-ISO/ndk3.2/fd/)

(trailing slash or not is the same result)

The path exists and contains all the .fd files.
Am I overlooking something?

[daxb]

Remove the brackets and try again.

[ugrnm]

Originally Posted by daxb

Remove the brackets and try again.

thanks
had no idea that parenthesis were like comments. work now!

[ugrnm]

In the end I had to tweak the suggested list a bit as I have an A600 + Fúria EC020, and things like MuFastZero does not working without an MMU, and my config has none if I understood correctly.

I settled on:

icon.library.51.4.570_FastWB
StackAttack
SaferPatches
BlazeWCP
FBlit
FText
CopyMemAIO
VBRControl

and the Fúria's own shadowrom command.

Things I'm not sure about are TLSFMem, and why FBlit/FText are greatly improving some aspects, but are performing not as well as a vanilla install on some SysSpeed tests (namely OpenWin, WinLayer, SizeWin, ScrollX, RectFill). I suppose this would need a thorough look at the options of the FBlitGUI and benchmark changes... I'm using the config from IconLib but have not see any diff from default install config.

[EctoOne]

Probably not a performance patch, but does anyone know if True Multi Assign http://aminet.net/package/util/cli/TRTrueMultis (or included in http://aminet.net/package/util/shell/ViNCEd) is still worth using on 3.2?

[Thomas Richter]

I wouldn't know why it shouldn't.