AmigaOS 3.2 performance vs 3.1

[patrik]

Originally Posted by Firestone

In this case, I guess "FastExec" is this one? : https://aminet.net/package/util/boot/FastExec30

I have only used the good old 2.9 version, but I suppose the newfangled one should work just fine too .

Originally Posted by Firestone

Can you please elaborate about "Not enabling the MMU on the 030 (with a fairly complicated config) ?

When the 030 MMU is enabled by mmu.library, you can measure a slowdown if you time something memory intensive.

If you enable the MMU by using something simpler, like remap the kickstart to fast using the 3.1 "Cpu FASTROM", at least I have not been able to measure a slowdown.

Just so nobody chimes in and says "but the system will get faster by doing that, it is not a valid test": tested this on an A3000 030@25MHz with the kickstart rom timing jumper set to the fastest setting, which means fastmem and rom has the same number of waitstates and the rom is 32-bit, so remapping kickstart to fast does not give a performance benefit.

The tests I did can be seen in the original thread I linked to: https://eab.abime.net/showthread.php...37#post1587137

Even if mmu.library is set to use the same 32kB page size as "Cpu FASTROM", you can measure a slowdown (much smaller than with default 1kB), so reasonably the MMU config or table must be fairly complicated in the mmu.library case compared to the "Cpu FASTROM" case, else it should not result in a slower system. Just remapping the kickstart rom should also reasonably be way less advanced than what a generic mmu library does.

Originally Posted by Firestone

Or is this just a matter of removing mmu.library and the 68k-libs from LIBS: ? And of course any MuTools from startup.

Yes, or 68030.library.

If you do the latter and remove 68030.library but keep mmu.library, it will stop being forcefully loaded by C:SetPatch at beginning of boot via 68030.library. So the MMU will not be enabled unnecessarily at boot, but if you want to run say MuForce you can still start it. If you do an "Avail flush" after stopping MuForce, mmu.library will expunge itself cleanly and disable the MMU, restoring performance.

[Thomas Richter]

Originally Posted by patrik

Even if mmu.library is set to use the same 32kB page size as "Cpu FASTROM", you can measure a slowdown (much smaller than with default 1kB), so reasonably the MMU config or table must be fairly complicated in the mmu.library case compared to the "Cpu FASTROM" case, else it should not result in a slower system.

There is nothing "complicated" in the setup. Actually, quite reverse, there is something "complicated" with "CPU FastROM" - the "trick", if you want to say so, is that it enables the TTx registers outside the 24-bit address space where the MMU is bypassed. This is "sometimes" correct, but not always. It is not correct if there is something to do for the MMU in the 32-bit address space, for example if an expansion maps there that does not support caching.


Thus, it is not a generally working or advisable solution. A typical example is if you have a Z-III graphics card with a blitter which modifies the memory bypassing the CPU. In "most cases" the conflict between the blitter and the CPU would not be noticed due to the miniature cache of the 68030, but that does not make the approach correct. It would neither work if you have 32-bit I/O registers in 32-bit memory (example: The CVision3D) which cannot be cached because they change "under the feed" of the CPU which attempts to cache them.

[Firestone]

Originally Posted by patrik

I have only used the good old 2.9 version, but I suppose the newfangled one should work just fine too .
When the 030 MMU is enabled by mmu.library, you can measure a slowdown if you time something memory intensive.

If you enable the MMU by using something simpler, like remap the kickstart to fast using the 3.1 "Cpu FASTROM", at least I have not been able to measure a slowdown.

Even if mmu.library is set to use the same 32kB page size as "Cpu FASTROM", you can measure a slowdown (much smaller than with default 1kB), so reasonably the MMU config or table must be fairly complicated in the mmu.library case compared to the "Cpu FASTROM" case, else it should not result in a slower system. Just remapping the kickstart rom should also reasonably be way less advanced than what a generic mmu library does.

The latest version of FastExec only contains one change, so no worries:

3.0 (29.4.22)
 · faster rolled Autovec

Now I'm back to a system I can settle down with again using Blizkick and FastExec with FASTSSP FASTVBR and FASTEXP.
But it requires a double reboot now. Not a huge problem, but if it can be avoided, that would be nice.
I guess the solution would then be to get the Blizkick module working, or are there any other approaches?

Thanks again for your excellent posts!

[Amiga68k]

Originally Posted by Firestone

Now I'm back to a system I can settle down with again using Blizkick and FastExec with FASTSSP FASTVBR and FASTEXP.
But it requires a double reboot now. Not a huge problem, but if it can be avoided, that would be nice.
I guess the solution would then be to get the Blizkick module working, or are there any other approaches?!

When the BlizKick modules stopped working when kicking a 3.1.4+ ROM, the most useful solution would be to update the BlizKick package to support this update. I contacted the author about this, but this seemed a dead end, I think he lost interest.

That's when I started my experiments to find out the correct order to reach the performance level I was used to. I learned the correct order and what commandline options to use for BlizKick and for LoadModule as previously stated, but both methods rely on MuTools.

There is actually a third method (and a fourth thanks to patrik) that I experimented with back then, but it has a couple of flaws:
- Huge commandline with EXTRESBUF
- The EXTRESBUF value is cherrypicked and most likely needs finetuning
- BlizKick doesn't properly support 3.1.4+ (3.1 ROM is mentioned for instance in WB About)

The major benefit here is that the individual BlizKick modules work again (BBlank, LocalFast and NoClick in below example). I can't remember exactly, because it has been a while, but I believe this only needs a single reboot as well. The line in question is:

C:BlizKick * EXTRESBUF=600000 audio.device battclock.resource bootmenu card.resource console.device exec.library FastFileSystem FileSystem.resource gameport.device graphics.library icon.library input.device intuition.library keyboard.device layers.library mathffp.library mathieeesingbas.library Ram-Handler ramdrive.device scsi.device Shell-Seg syscheck timer.device trackdisk.device utility.library workbench.library BBlank LocalFast NoClick QUIET

It's huge! Because of the previously mentioned flaws, I stopped this experiment here.

One sidenote: I'm using a 3.1 ROM here, not entirely sure what the above does when having a 3.0 ROM version as you previously stated..

[DanyPPC]

I own a Blizzard 1230mkIV and I use Blizkick:

C:Blizkick Devs/Kickstart/Kick47111.A1200 MuMove4K SpeedyIDE QUIET
SetPatch QUIET
C:MuFastZero FastExec FastSSP QUIET

With these lines I get 32BitRam usage for all libraries except for:

expansion.library (FAST RAM)
exec.library (FAST RAM)

but system works well.

If I use FastExec:

C:Blizkick DEVS/Kickstart/Kick47111.A1200 SpeedIDE QUIET
C:FastExec FastEXP FastSSP REBOOT

I have 2 reboots, the system seems works as first but I have all libraries/devs in 32BitRam, also:

expansion.library (32BitRam)
exec.library (32BitRam)

What is the difference from Fast Ram and 32BitRam from first and second solution ?
Thanks.

[Thomas Richter]

Without knowing the details, hard to say. Thus, to answer your question, I would need the base addresses of the libraries, and the output of MuScan.

[Don_Adan]

And about LONG vs ULONG "dos/dos.h defines it to be a LONG".
This is buggy, must be ULONG.
File length cant be negative value. This is logical.
Amiga OS 3.9 handle this as ULONG, and can display file sizes up to 4GB.
But You perhaps know this.

[Thomas Richter]

Originally Posted by Don_Adan

And about LONG vs ULONG "dos/dos.h defines it to be a LONG".
This is buggy, must be ULONG.
File length cant be negative value. This is logical.
Amiga OS 3.9 handle this as ULONG, and can display file sizes up to 4GB.
But You perhaps know this.

Again, there is one crucial thing you do not seem to get: This does not fix old software, and it is not just "for showing file lengths". Thus, this is not a "generally working" way of how to make "long files work". After all, it is just one bit. How a file system reacts on such long files is probably yet another issue.

[DanyPPC]

Originally Posted by Thomas Richter

Without knowing the details, hard to say. Thus, to answer your question, I would need the base addresses of the libraries, and the output of MuScan.

These from MuMove4K + MuFastZero:
https://eab.abime.net/attachment.php...1&d=1712747586
https://eab.abime.net/attachment.php...1&d=1712747654

These from FastExec 3.0:
https://eab.abime.net/attachment.php...1&d=1712747697
https://eab.abime.net/attachment.php...1&d=1712747711

OT: I have a doubt and I don't know if it is related to OS 3.2. I have a 16GB Internal CF card formatted and prepared with OS 3.2 (3 x partitions 1GB + 7GB + 7GB). I use Blizkick to map Kick 47.111 but in hardware I own Kick 40.068 (3.1). My doubt is, why if I boot (first start) to shell (boot without s-s), so I'm using Kick 3.1 I can see and use the 3 partitions ?
I know that Kick 3.1 can use up to 8GB with updated FFS and only 2GB x partition.
Could this be related to OS 3.2 prepared and installed mode ?
Sorry for the OT.

[Thomas Richter]

Originally Posted by DanyPPC

These from MuMove4K + MuFastZero:
https://eab.abime.net/attachment.php...1&d=1712747586
https://eab.abime.net/attachment.php...1&d=1712747654

These from FastExec 3.0:
https://eab.abime.net/attachment.php...1&d=1712747697
https://eab.abime.net/attachment.php...1&d=1712747711

From the perspective of the CPU, the two variants are equivalent because the libraries are in fast in both cases, though by different means.

Originally Posted by DanyPPC

OT: I have a doubt and I don't know if it is related to OS 3.2. I have a 16GB Internal CF card formatted and prepared with OS 3.2 (3 x partitions 1GB + 7GB + 7GB). I use Blizkick to map Kick 47.111 but in hardware I own Kick 40.068 (3.1). My doubt is, why if I boot (first start) to shell (boot without s-s), so I'm using Kick 3.1 I can see and use the 3 partitions ?

A doubt? Or a question? (Note the difference). As always, it depends. If you pick a file system 3.1 has in ROM (e.g. FFS-INTL, DOS\03), no issue. If you pick a file system 3.1 has not in ROM (e.g. FFS with long file names, FFS\07), then in order to use this partition from 3.1, the FFS *also* needs to be in the RDB. If the partition crosses a 4GB boundary, then the RDB also needs to be in the RDB to make it work under 3.1.

[DanyPPC]

Many thanks Thomas for the clarification

[Don_Adan]

Originally Posted by Thomas Richter

Again, there is one crucial thing you do not seem to get: This does not fix old software, and it is not just "for showing file lengths". Thus, this is not a "generally working" way of how to make "long files work". After all, it is just one bit. How a file system reacts on such long files is probably yet another issue.

Which old software You want to fix? And for what?
Same bug/limitation was for HD partition sizes, it was defined as LONG not ULONG.
Then for older kicks You can see negative values as partition sizes.
For all partitions greater than 2GB.
Someone fixed old software which shows wrong partition sizes?
No. Except new programs or new program versions.
Same will be for 2GB limit for file sizes.
Newest programs can handle (show) file sizes as ULONG, even if this is buggy declared as LONG in dos.h.
This is called progress.
Now for Amiga You can connect f.e PiStorm.
This is another progress, hardware progress. Very fast CPU and very fast graphic cards.
But with Amiga OS/kickstart limits (size of memory and size of files) from 1985 year.
No true software progress, except some visuals.

[Thomas Richter]

Originally Posted by Don_Adan

Which old software You want to fix? And for what?

Consider programs showing disk content. For large files, they will just show the wrong number. Consider a copy program that allocates buffers or space on the target according to the size in the file info block. We cannot fix them, but we can avoid that major havoc happens if you use such programs. For example, by not showing them in the directory unless the right function is called, or by creating an error if you attempt to get information on them with the wrong functions.


A little bit more care is needed.

Originally Posted by Don_Adan

This is called progress.

Progress? Amiga? Let's be real, please. This is really a historic system, and not a productive environment. There is not really a use case for such large files. Will you view DVDs on the Amiga? No. Burn them? No.

[SpeedGeek]

Originally Posted by Thomas Richter

There is nothing "complicated" in the setup. Actually, quite reverse, there is something "complicated" with "CPU FastROM" - the "trick", if you want to say so, is that it enables the TTx registers outside the 24-bit address space where the MMU is bypassed. This is "sometimes" correct, but not always. It is not correct if there is something to do for the MMU in the 32-bit address space, for example if an expansion maps there that does not support caching.

Thus, it is not a generally working or advisable solution. A typical example is if you have a Z-III graphics card with a blitter which modifies the memory bypassing the CPU. In "most cases" the conflict between the blitter and the CPU would not be noticed due to the miniature cache of the 68030, but that does not make the approach correct. It would neither work if you have 32-bit I/O registers in 32-bit memory (example: The CVision3D) which cannot be cached because they change "under the feed" of the CPU which attempts to cache them.

I did not know that CPU FastROM enabled the TTx registers outside the 24 bit address space. I don't see any reason to do this unless you are trying to make the Zorro3 space cache inhibited. I thought the main trick was the early (24 bit address space) termination the MMU tables.

It seems that P5 had worked around the CVision3D Board issue with their 030 CGX driver. I didn't find anything in the CVision3D manual requiring anything but the 030 CGX driver.

[Thomas Richter]

Originally Posted by SpeedGeek

I thought the main trick was the early (24 bit address space) termination the MMU tables.

The mmulib uses early termination on the 68030 and below whenever possible. Actually, early termination does not buy you anything in terms of "amount of lookups" needed - each entry in the ATC cache is only for a single page, and thus an early termination page descriptor allocates multiple ATC cache entries.

Originally Posted by SpeedGeek

It seems that P5 had worked around the CVision3D Board issue with their 030 CGX driver. I didn't find anything in the CVision3D manual requiring anything but the 030 CGX driver.

From the manuals I have, it says that you are supposed to run "Enforcer QUIET".

[Amiga68k]

Originally Posted by DanyPPC

I own a Blizzard 1230mkIV and I use Blizkick:

C:Blizkick Devs/Kickstart/Kick47111.A1200 MuMove4K SpeedyIDE QUIET

Thanks for this addition! I just retested the use of MuMove4K together with BlizKick and that is indeed confirmed working (unfortunately the LocalFast module is still borked in this scenario). This implicates that also the BlizKick and MuFastZero combination only needs a single reboot. Good to know.

Currently that brings us to 4 methods to get exec in Fast when using our Blizzard cards:

1 reboot
- LoadModule + MuMove4K + MuFastZero
- BlizKick + MuMove4K + MuFastZero
- BlizKick extravaganza commandline in combination with LocalFast (and the possibility to disable the mmu stuff (?), haven't tested this yet)

2 reboots
- BlizKick + FastExec (and the possibility to disable the mmu stuff)

[SpeedGeek]

Originally Posted by Thomas Richter

The mmulib uses early termination on the 68030 and below whenever possible. Actually, early termination does not buy you anything in terms of "amount of lookups" needed - each entry in the ATC cache is only for a single page, and thus an early termination page descriptor allocates multiple ATC cache entries.

From the manuals I have, it says that you are supposed to run "Enforcer QUIET".

Of course it does. There are only a limited number of ATC entries and managing the full 32 bit of address space means the entries are flushed more often, resulting in more ATC misses and more physical memory MMU table searches.

The CVision643D manual I used was from here:

http://amiga.resource.cx/exp/cybervision643d

I see nothing about using "Enforcer" in the English part of the Manual. Was it in the German part or were you using a different manual?

[Thomas Richter]

Originally Posted by SpeedGeek

Of course it does. There are only a limited number of ATC entries and managing the full 32 bit of address space means the entries are flushed more often, resulting in more ATC misses and more physical memory MMU table searches.

Sigh. This is *not* how early termination page descriptors work. Again, each *page* allocates an entry, and not *each descriptor*. Yes, that's silly, but that's how the 68030 MMU works.

[SpeedGeek]

Originally Posted by Thomas Richter

Sigh. This is *not* how early termination page descriptors work. Again, each *page* allocates an entry, and not *each descriptor*. Yes, that's silly, but that's how the 68030 MMU works.

It sounds like you are reading or understanding this differently than me. I am not referring to early termination of table descriptors, rather early termination of the MMU tables.

[Thomas Richter]

Originally Posted by SpeedGeek

It sounds you are reading or understanding this differently than me. I am not referring to early termination of table descriptors, rather early termination of the MMU tables.

68030UM, page 9-34. Read it. Please. There is no advantage in early termination - in terms of memory, yes. In terms of speed, no.