English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 16 July 2019, 00:42   #21
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 51
Posts: 1,140
Quote:
Originally Posted by ross View Post
Hi Don, I'll sure do (not today) some tests vs Arjm7, Pack fire (both), ProPack and Shrinkler.
Well, actually not directly comparable because the very different algos and speed classes.
But sure interesting.
For depacker test, for LZMA you can use 68000 (optimised, but slow), 68020 (original is not optimised) versions. For Shrirnkler you can test latest xpk versions from Cholok, with optimised depacker, xpkSHRI and xpkSHR3. SHRI3 has fastest depacking about 25% if i remember right. Still slow, but better than original SHRI, beceuse less divide instructions. For your depack sources, if I remember right move.l A4,A0 is fastest than lea (A4),A0 for 68000.

bne.b L_rep can be replaced with bne.b/w decompr_loop, i think too.

Last edited by Don_Adan; 16 July 2019 at 01:06.
Don_Adan is offline  
Old 16 July 2019, 02:14   #22
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,823
Quote:
Originally Posted by Don_Adan View Post
For depacker test, for LZMA you can use 68000 (optimised, but slow), 68020 (original is not optimised) versions.
Ok.
I don't think I have the 68020 version (but I can write it).
In any case I can't compare it with the other (pure 68k) algorithms with my current test bench (for a bare A500, see first thread message).

Quote:
For Shrirnkler you can test latest xpk versions from Cholok, with optimised depacker, xpkSHRI and xpkSHR3. SHRI3 has fastest depacking about 25% if i remember right. Still slow, but better than original SHRI, beceuse less divide instructions.
Thanks for the references.
But by Shrinkler I mean the Blueberry (awesome) CM packer.
(https://github.com/askeksa/Shrinkler)

Quote:
For your depack sources, if I remember right move.l A4,A0 is fastest than lea (A4),A0 for 68000.
Not by my 68k reference manual:
movea.l an,an 4(1/0)
lea (an),an 4(1/0)


Quote:
bne.b L_rep can be replaced with bne.b/w decompr_loop, i think too.
It's a choice.
If you follow the flow this instruction is executed only one time, so i'm trading insignificant cycles (from millions) for two bytes
[EDIT: I mean that the branch is taken only one time, so on second run (the not taken) bne.b is 4 cycles faster than the
'natural' bne.w to decompr_loop. Even less loss of cycles than expected ]

Cheers!

Last edited by ross; 16 July 2019 at 02:31. Reason: bne.b/bne.w
ross is offline  
Old 16 July 2019, 02:32   #23
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 51
Posts: 1,140
Quote:
Originally Posted by ross View Post
Ok.
I don't think I have the 68020 version (but I can write it).
In any case I can't compare it with the other (pure 68k) algorithms with my current test bench (for a bare A500, see first thread message).


Thanks for the references.
But by Shrinkler I mean the Blueberry (awesome) CM packer.
(https://github.com/askeksa/Shrinkler)


Not by my 68k reference manual:
movea.l an,an 4(1/0)
lea (an),an 4(1/0)



It's a choice.
If you follow the flow this instruction is executed only one time, so i'm trading insignificant cycles (from millions) for two bytes

Cheers!
Originally Pack Fire (LZMA) has only 68020+ depacker, because 68020 commands. You can easy restored 68020 version, use 68020 adressing modes and one mul.l only for 68000 optimised version. On Amiga xpk_SHRI has very good compression, but very slow depacking. I never tested Shrinkler because was not available, when I tested 68k packers. You right lea and move.l has same speed for 68000, i dont know why I thinked than move.l is better.
Don_Adan is offline  
Old 23 July 2019, 23:08   #24
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,823
Beaten!

Code:
file: Zombies.SHP                 
dim:  245720                  
                                                
        pack_to  ratio    KB/s            
gzip    52415   21,331%   91,51           
appack  49293   20,061%   84,46           
nrv2b   46941   19,103%  145,82          
aplibx  46779   19,038%  154,73          
nrv2s   46902   19,088%  174,51
nrv2r   46238   18,817%  162,19 
nrv2r suppor in-place and a0=a1.
A few slower that nrv2s but I've to quantify it (the unpacker is almost finished..)



EDIT: added nrv2r decode speed, the loss of speed for the case 'in-place and no buffer offset' is absolutely acceptable
this will satisfy even the lazy programmers, just pass as the only parameter the initial address of the buffer where the data are loaded and you are done

Last edited by ross; 25 July 2019 at 23:47. Reason: added nrv2r decode speed
ross is offline  
Old 28 July 2019, 18:57   #25
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,699
I made hundreds of analysis runs before I wrote the first line of compressor code for Nibbler. Decompression speed will depend on the exact data, so it's important to measure a spread of data types used on the platform, and perhaps agree on a few exact files to represent this spread.

Here are a few of the runs for a few widely used decompressors with known and identical data.

It makes sense to use floppy speed as a decompression speed benchmark (for 68000), and I used it too. Nibbler decompresses at an average 5.33x floppy speed while achieving ratios near LHA.
Photon is offline  
Old 28 July 2019, 21:50   #26
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,823
Hi Photon, I wanted to try Nibbler and I put in compression a file from your testbed (Kickstart 3.1 rev 40.68 A1200 ROM) to make comparison, I wasn't sure about other files version.
EDIT: Nibbler took a long time but finally concluded

My results:
Code:
Kickstart v3.1 rev 40.68 524.288
Nibbler  320801
LhA      319077
Gzip -9  312957
nrv2r    304222
I have not done decompression speed tests, however if I find the time I'll have to do a series of deep tests including all the compressors mentioned in the thread.

Last edited by ross; 28 July 2019 at 22:18.
ross is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Help us test our new game on real hardware alpine9000 Retrogaming General Discussion 26 08 June 2016 09:21
PPC68k20 did anyone test this on real hardware? Michael Sykes Amiga scene 0 21 January 2016 00:07
How to test time for piece of code Powergoo Coders. Asm / Hardware 16 17 October 2015 23:08
ALWAYS test your code on real hardware!! h0ffman Coders. General 32 16 July 2015 21:02
Time Soldier v1.3 Uploaded to the Zone (Please Test and Provide Feedback) Abaddon project.WHDLoad 0 17 December 2010 19:33

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:19.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.06618 seconds with 14 queries