060 performance issues traced to ATC misses?

[alexh]

Over on EAB there has been a discussion about why a 1260 was much slower than a 1230 in a particular new application. The usual "60 chip ram speed" debate was taking place when a very talented coder "paraj" discovered bypassing the MMU using the TTR improved the 1260 performance. Speculation is that address translation cache misses were causing the performance penalties on the 060 vs 030.

https://eab.abime.net/showpost.php?p=16 ... stcount=69

I don't really understand how prevalent this effect is but I thought I'd repost here in case it was interesting to anyone?

[czietz]

As a side note, you can also see the ATC in effect on a 68030, as I've shown many years ago:
https://www.atari-forum.com/viewtopic.p ... 10#p390410

[Cyprian]

Over on EAB there has been a discussion about why a 1260 was much slower than a 1230 in a particular new application. The usual "60 chip ram speed" debate was taking place when a very talented coder "paraj" discovered bypassing the MMU using the TTR improved the 1260 performance. Speculation is that address translation cache misses were causing the performance penalties on the 060 vs 030.

https://eab.abime.net/showpost.php?p=16 ... stcount=69

I don't really understand how prevalent this effect is but I thought I'd repost here in case it was interesting to anyone?

sounds interesting but
Unfortunately there is an issue with EAB: "The server is too busy at the moment. Please try again later."

[mikro]

I couldn't read the original discussion either but that argument is quite weird -- ATC is present in both CPUs. Also, as Christian's thread on AF confirmed, 060 does not suffer from ATC cache misses that much. So most likely the test with MMU is just red herring.

[alexh]

The EAB server is being updated at the moment.

It's not a red herring. ATC cache misses are definitely the cause of the slowdown on the 060 platform being used to test this application.

The exact cause for the differences is not 100% understood. 030 MMU and 060 MMU are quite different animals *AND* there is no data if the MMU was even enabled and mapped on the 030 runs where it was on the 060 runs.

As I tried to explain with my wording this is an effect seen in one use of one application in one environment and is not a general statement but it is an interesting discovery for anyone wrestling with unusually low 060 performance.

[matt020]

Does this mean it's time to sell our 060's and move to 030 cards?

[alexh]

Does this mean it's time to sell our 060's and move to 030 cards?

Wanna swap? I'm sure I can find you an old 1230 :)

This is at worst an MMU configuration issue and at best nothing, an interesting observation.

But the question I was trying to get people to ask is if it is a configuration issue, whether it is a widespread configuration issue?

i.e. Does it affect all applications? Every AmigaOS installation that uses MMULib?

Or is it this one, unusual, application that just happens to cause lots of ATC page refreshes? Or a system that has an unusual MMU configuration?

[matt020]

This is at worst an MMU configuration issue and at best nothing, an interesting observation.

All over one app? or is it numerous apps? It's just one app, isn't it?

[alexh]

All over one app? or is it numerous apps? It's just one app, isn't it?

That's the big question. I have no evidence but it could be numerous apps.

In the 060 world, it is normal to always install MMULibs and always have the MMU enabled to remap your kickstart and VBR to fastRAM etc.

This particular application appears to cause ATC page thrashing which results in a measurable performance loss. It's not unrealistic to wonder if the same could be happening with other applications on 060 which are being executed from MMU mapped memory when they don't need to be.