ATARI depacking benchmark

[leonard]

Here's the results from my TT, MSTE and Falcon (3 machines, 3 different monitors, 1 phone ghetto cam so bare with me!)

Thanks ggn! It's really interesting. I'm surprised how falcon is "really not so fast" compared to TT or 16Mhz MSTE!
I guess your TT is 32Mhz right? it's faster than falcon, that's insane!

[ggn]

Here's the results from my TT, MSTE and Falcon (3 machines, 3 different monitors, 1 phone ghetto cam so bare with me!)

Thanks ggn! It's really interesting. I'm surprised how falcon is "really not so fast" compared to TT or 16Mhz MSTE!
I guess your TT is 32Mhz right? it's faster than falcon, that's insane!

The TT is 32Mhz, that's correct. As for the Falcon not that faster... I guess things could improve if we recoded the depackers to take advantage of the 030's instruction cache and/or turning data cache off. I'm sure the depackers are optimised for 68000 and speed in mind. One final thing to note is that the TT has a proper 32-bit bus so that probably plays the decisive factor for its speed.

[troed]

latest news: I modify "We Were @" demo installer to use upx --nrv2b, and first floppy won't fit! All screens are bigger than arj -m7! I keep arjbeta -m7 for my demos

Thanks for testing leonard, this is very valuable information. arj -m7 packs better, nrv2b has a smaller depacker and is faster. When I selected UPX (nrv2b) for {Closure} I was under the impression it was clearly better than other options - now I know better

(I don't depack while loading so my total loading times, when not doing that, are still lower with nrv2b. That's of course my problem )

/Troed

[AtariZoll]

If you read UPX docs, will see that NRV is considered as outdated, and they went on LZMA method, because it has much better pacing ratio. But TOS file packing never uses LZMA method unless you specify it in command line. I did not try it so far, and wow - it packs really much better. 525KB long file, with some empty areas was packed with NRV to some 95KB, while with LZMA it is 75KB . That's the good part. Bad part is that depacking is really slow - took over 100 secs for mentioned 525KB file. I tried with --fast switch, but it was not faster.
Good thing is that it is open source, so can pack any file without TOS header trickery. Depacker code is slow, and much longer. May be useful if space is tight and speed not so relevant - or just in case of many short files. LZMA is used in 7z too.

[troed]

If you read UPX docs, will see that NRV is considered as outdated, and they went on LZMA method, because it has much better pacing ratio.

When I updated the existing code to work with new versions of UPX I indeed ran into this (and that's why I specify nrv2b manually on the command line). I do recall they (UPX) were quite open with that the better packing method was very slow in comparison. Thanks for verifying.

/Troed

[Cyprian]

Here's the results from my TT, MSTE and Falcon (3 machines, 3 different monitors, 1 phone ghetto cam so bare with me!)

Thanks ggn! It's really interesting. I'm surprised how falcon is "really not so fast" compared to TT or 16Mhz MSTE!
I guess your TT is 32Mhz right? it's faster than falcon, that's insane!

The TT is 32Mhz, that's correct. As for the Falcon not that faster... I guess things could improve if we recoded the depackers to take advantage of the 030's instruction cache and/or turning data cache off. I'm sure the depackers are optimised for 68000 and speed in mind. One final thing to note is that the TT has a proper 32-bit bus so that probably plays the decisive factor for its speed.

I would say that compression code only takes advantage of MHz

Atari_compression.png

Interesting is that how decompressed data are saved in the RAM - Byte after Byte?

[AtariZoll]

...
Interesting is that how decompressed data are saved in the RAM - Byte after Byte?

Indeed. But that's not what makes it slow. Fastest depackers are for LZO type compressions - where only literals and sliding matches are used - so no need for bit shifts and other slow operations of packed data. 300KB/sec is achievable on 8MHz 68K. Best packers use combined methods for getting good rarios, but that needs complex depackers too, and they are slow, of course, especially on perhistoric CPUs

[DarkLord]

Sorry I'm late to the party.

Here's my 40mhz 68030, 40mhz 68882, TOS v3.06 equipped Pak 68/3 STacy.

(does the routine take advantage of FPUs?)

P1010006.JPG

BTW, how do you cleanly stop the test? I ran it from an 2gig SDcard in my Ultrasatan.

I tried q, s, x, esc, <control> q, s, x, etc.

PS Dal, still running up a against a brick wall whenever I try to upload files. The forum says file
sizes are limited to 500kib. I can't upload anything over 200.... Thanks.

[leonard]

Here's my 40mhz 68030, 40mhz 68882, TOS v3.06 equipped Pak 68/3 STacy.

Thanks for these new numbers! I don't know there is some 40Mhz version of TT, but it seems it's a veru fast machine!

(does the routine take advantage of FPUs?)

not at all

BTW, how do you cleanly stop the test?

you can't. The benchmark ends in an infinite loop

[DarkLord]

Oh, the STacy is an Atari portable (although at its weight, "luggable" might
be a better description!).

It's not a TT at all. It's pretty much a standard TOS v1.04, 8mhz 68000, max 4 meg
ST at heart.

I installed a Pak 68/3 accelerator board in it. That gives it TOS v3.06, a 40mhz 68882 FPU,
and a 40mhz 68030 CPU.

Quick little machine.

stacy-full.jpg

[leonard]

Oh, the STacy is an Atari portable (although at its weight, "luggable" might
be a better description!).

Oh sorry I missed that! Of course I know Stacy by name, but don't know about the acceleration card. That's really a fast ST!