Page 1 of 2 12 LastLast
Results 1 to 30 of 41

Thread: miniCRUSH 1.00

  1. #1
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts

    miniCRUSH 1.00

    Good evening!

    I've spent plenty of time lately attempting to make the smallest, most compact, portable binaries for file compressors without using any EXE packer or modifying the source code.

    So today I am sharing with you guys my "minimized" compiled version of one of my favorite compressors, CRUSH 1.00!

    Notes:
    - The line that shows the final result after compression (old size, new size) was removed due to compiler issues (and I couldn't figure out how to fix it).
    - No performance loss.

    Let me explain this a different way:
    Code:
        CRUSH : 110,592 bytes
    miniCRUSH :   9,216 bytes
       SOURCE :   7,891 bytes
    Just imagine how many more bytes of data can be stored on your 3.5" floppy disk!

    Enjoy and please report any errors and suggestions!

    EDIT: I was able to get it even smaller but then decompression speed decreased by ~20% and that is unacceptable for a program like CRUSH.

    EDIT #2 Since writing this post, this has become a competition. For those who want to join in the competition, please note that your build will be disqualified if the decompression speed is 10% slower. If it is 11-12%, that's fine because all CPUs are different.
    Attached Files Attached Files
    Last edited by comp1; 7th March 2016 at 21:14.

  2. Thanks:

    encode (1st March 2016)

  3. #2
    Member nikkho's Avatar
    Join Date
    Jul 2011
    Location
    Spain
    Posts
    554
    Thanks
    223
    Thanked 166 Times in 107 Posts
    Quote Originally Posted by comp1 View Post
    Good evening!

    I've spent plenty of time lately attempting to make the smallest, most compact, portable binaries for file compressors without using any EXE packer.

    So today I am sharing with you guys my "minimized" compiled version of one of my favorite compressors, CRUSH 1.00!

    Notes:
    - The line that shows the final result after compression (old size, new size) was removed due to compiler issues (and I couldn't figure out how to fix it).
    - No performance loss.

    Let me explain this a different way:
    Code:
        CRUSH : 110,592 bytes
    miniCRUSH :   9,216 bytes
       SOURCE :   7,891 bytes
    Just imagine how many more bytes of data can be stored on your 3.5" floppy disk!

    Enjoy and please report any errors and suggestions!

    EDIT: I was able to get it even smaller but then decompression speed decreased by ~20% and that is unacceptable for a program like CRUSH.

    Seems a pretty nice reduction.
    Maybe it can be further reduced if you post the source code.

  4. #3
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts
    Quote Originally Posted by nikkho View Post
    Seems a pretty nice reduction.
    Maybe it can be further reduced if you post the source code.
    Source is unchanged.

  5. #4
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,610
    Thanks
    30
    Thanked 65 Times in 47 Posts
    It would be nice if you explained your techniques then.

  6. #5
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts
    Quote Originally Posted by m^2 View Post
    It would be nice if you explained your techniques then.
    I can't share my tricks but I'd be happy to compile minimized versions of other compressors if you'd like.

  7. #6
    Member nikkho's Avatar
    Join Date
    Jul 2011
    Location
    Spain
    Posts
    554
    Thanks
    223
    Thanked 166 Times in 107 Posts
    Quote Originally Posted by comp1 View Post
    I can't share my tricks but I'd be happy to compile minimized versions of other compressors if you'd like.
    Do not see the point to be honest.

  8. #7
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts
    Quote Originally Posted by nikkho View Post
    Do not see the point to be honest.
    For those who want to save every last byte. Making these minimized versions is fun, nothing more. If someone finds this (and possibly other) mini builds useful, then that's great.

  9. #8
    Member nikkho's Avatar
    Join Date
    Jul 2011
    Location
    Spain
    Posts
    554
    Thanks
    223
    Thanked 166 Times in 107 Posts
    Quote Originally Posted by comp1 View Post
    For those who want to save every last byte. Making these minimized versions is fun, nothing more. If someone finds this (and possibly other) mini builds useful, then that's great.
    Maybe, but the interesting thing is to know how to achieve it.
    On one side, you said source code was the same, so I asume you linked against a minimal RTL, or used different compilation switches.
    But then you said you removed the line showing the result, so indeed, source was modified.

  10. #9
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts
    Quote Originally Posted by nikkho View Post
    Maybe, but the interesting thing is to know how to achieve it.
    On one side, you said source code was the same, so I asume you linked against a minimal RTL, or used different compilation switches.
    But then you said you removed the line showing the result, so indeed, source was modified.
    Let me clarify:

    1) You are correct that all the minimizing was done at the compilation stage.

    2) I removed that particular line because I was not able to compile with it. THat line prints the old file size and the new file size after compression is complete--hardly a performance-demanding/size-demanding line of code, wouldn't you agree?

    That line was removed from the source because of my lack of ability to compile--if that line would have been part of the algorithm, that's a different story. This was a simple "printf" line.

    Hope that clears things up.

  11. #10
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    688
    Thanks
    41
    Thanked 174 Times in 88 Posts
    Quote Originally Posted by nikkho View Post
    Seems a pretty nice reduction.
    Original crush.exe statically compiled with Visual Studio 2010 and has imports to WinAPI level kernel32.dll file only, without any external runtimes dependencies.

    Quote Originally Posted by m^2 View Post
    It would be nice if you explained your techniques then.
    Quote Originally Posted by nikkho View Post
    Maybe, but the interesting thing is to know how to achieve it.
    Quote Originally Posted by comp1 View Post
    I can't share my tricks but I'd be happy to compile minimized versions of other compressors if you'd like.
    There are no tricks and there are no techniques.
    miniCrush dynamically compiled with Visual Studio 6.0 with linking against the MSVCRT.dll.
    Somebody will say: "Wait a minute, why dynamically? msvcrt.dll is the part of almost any version of Windows!"
    No doubt. But technically msvcrt.dll is the C and C++ runtime so linking to it means taking a lot of code out of the exe body.
    Anyway here is the 8481 byte version.
    Attached Files Attached Files

  12. Thanks (3):

    encode (5th March 2016),Mike (5th March 2016),nikkho (5th March 2016)

  13. #11
    Member nikkho's Avatar
    Join Date
    Jul 2011
    Location
    Spain
    Posts
    554
    Thanks
    223
    Thanked 166 Times in 107 Posts
    Quote Originally Posted by Skymmer View Post
    Original crush.exe statically compiled with Visual Studio 2010 and has imports to WinAPI level kernel32.dll file only, without any external runtimes dependencies.
    Thanks for revealing comp1 trick. I imagined something like that.

  14. #12
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts
    Quote Originally Posted by Skymmer View Post
    Original crush.exe statically compiled with Visual Studio 2010 and has imports to WinAPI level kernel32.dll file only, without any external runtimes dependencies.




    There are no tricks and there are no techniques.
    miniCrush dynamically compiled with Visual Studio 6.0 with linking against the MSVCRT.dll.
    Somebody will say: "Wait a minute, why dynamically? msvcrt.dll is the part of almost any version of Windows!"
    No doubt. But technically msvcrt.dll is the C and C++ runtime so linking to it means taking a lot of code out of the exe body.
    Anyway here is the 8481 byte version.
    Competition is fun!

    Skymmer's compile was too bloated for me! Here is my new build at 7,680 bytes!

    If speed were not so critical, we could go MUCH smaller!

    Enjoy!
    Attached Files Attached Files

  15. #13
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    688
    Thanks
    41
    Thanked 174 Times in 88 Posts
    Here comes 6944 bytes
    Attached Files Attached Files

  16. Thanks:

    nikkho (6th March 2016)

  17. #14
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts
    Quote Originally Posted by Skymmer View Post
    Here comes 6944 bytes
    6,656 bytes
    Attached Files Attached Files

  18. #15
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    688
    Thanks
    41
    Thanked 174 Times in 88 Posts
    5920
    Attached Files Attached Files

  19. Thanks (3):

    encode (6th March 2016),fhanau (6th March 2016),nikkho (6th March 2016)

  20. #16
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts
    Quote Originally Posted by Skymmer View Post
    5920
    I think it's fair to crown you as the winner.

    The only way I can get smaller is by losing noticeable speed.

    Good job, congrats!

  21. #17
    Member nikkho's Avatar
    Join Date
    Jul 2011
    Location
    Spain
    Posts
    554
    Thanks
    223
    Thanked 166 Times in 107 Posts
    Glad you were the winner Skymmer!

    Could you explain the compilation changes to go from 9216 to 5920?

  22. #18
    Member
    Join Date
    Apr 2015
    Location
    Greece
    Posts
    115
    Thanks
    39
    Thanked 30 Times in 21 Posts
    For Linux users
    64 bit 6176 bytes
    32 bit 5160 bytes

    removing the last line like above can make the 32 bit version under 5000 bytes
    Attached Files Attached Files

  23. Thanks:

    nikkho (6th March 2016)

  24. #19
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts
    Quote Originally Posted by Skymmer View Post
    5920
    I guess I crowned a winner too soon! Let's keep it going folks!

    5,632 bytes

    Also about 6.5% faster for decompression than Skymmer's version in my tests on my i7 3770k.
    Attached Files Attached Files
    Last edited by comp1; 6th March 2016 at 22:36.

  25. Thanks:

    encode (6th March 2016)

  26. #20
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts
    5,120 bytes

    ENWIK9
    Code:
    DECOMP  VERSION
    =====================
    10.077  ILYA
    10.420  SKYMMER_5920
    10.498  COMP1
    Attached Files Attached Files
    Last edited by comp1; 7th March 2016 at 00:55.

  27. #21
    Member
    Join Date
    Aug 2015
    Location
    Urbana, IL
    Posts
    159
    Thanks
    10
    Thanked 162 Times in 90 Posts
    Whoa! But how?

  28. #22
    Member
    Join Date
    Apr 2015
    Location
    Greece
    Posts
    115
    Thanks
    39
    Thanked 30 Times in 21 Posts
    An other one for Linux
    32 bit 4788
    64 bit 5720
    Attached Files Attached Files

  29. Thanks:

    encode (7th March 2016)

  30. #23
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    688
    Thanks
    41
    Thanked 174 Times in 88 Posts
    Ok. Here comes the 4031 bytes version.
    And another experimental one with size of 1688 bytes.
    Attached Files Attached Files

  31. #24
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts
    Quote Originally Posted by Skymmer View Post
    Ok. Here comes the 4031 bytes version.
    And another experimental one with size of 1688 bytes.
    The 1688 byte version does not work.

    But wow...4031 bytes..WOW!

    One clear difference between your builds and mine are that the filesizes are not rounded to the nearest .5KB like mine are.

    From what I've learned so far either you are stripping away code from the final executable file or you are not using MSVC link program

    Either way--great job sir!!!

    EDIT: Your latest version does not meet the requirements...HUGE performance loss:
    Code:
    DECOMP  VERSION
    =====================
    22.744  SKYMMER_4031 
    10.358  COMP1_5120

  32. #25
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    688
    Thanks
    41
    Thanked 174 Times in 88 Posts
    Man, I don't really care about your "runtime-generated" rules. This competition is about the exe size.

  33. Thanks:

    nikkho (7th March 2016)

  34. #26
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts
    Quote Originally Posted by Skymmer View Post
    Man, I don't really care about your "runtime-generated" rules. This competition is about the exe size.
    That's ok "man", I don't really care about your attitude issues. I happily crowned you the winner earlier and you get upset when someone points out that your build has some performance loss. CRUSH at that speed makes it lose its magic.

    As I mentioned earlier in this thread, exe size is as important as maintaining performance:

    EDIT: I was able to get it even smaller but then decompression speed decreased by ~20% and that is unacceptable for a program like CRUSH.
    But hey, congratulations on making a 4031 byte version that decompresses 54.5% slower.

    I PM'd you for tips/hints but now it's clear that the only thing you do differently is somehow remove the extra padding that rounds the exe filesize up to the nearest .5KB.

  35. #27
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    688
    Thanks
    41
    Thanked 174 Times in 88 Posts
    OK. Please provide the precise rules of this competition. How much of performance drop is accepted and so on. As for
    but now it's clear that the only thing you do differently is somehow remove the extra padding that rounds the exe filesize up to the nearest .5KB.
    then you're wrong. Even if not - cmon, do the same.

  36. Thanks:

    nikkho (7th March 2016)

  37. #28
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts
    Quote Originally Posted by Skymmer View Post
    OK. Please provide the precise rules of this competition. How much of performance drop is accepted and so on. As for

    then you're wrong. Even if not - cmon, do the same.
    Sure, let's say no more than 10% speed loss. If someone's build is 11% slower, that's fine--but 15%+ is too much. I'll update the first post for new arrivals who want to compete.

    Also, here is my 4096 bytes version which I've been able to achieve for some time but the performance loss is roughly 10%.

    Again, my exe is rounded up to 4KB. Looking at the sections in my fileexe though, the .data is 3072 bytes and the .rdata is 496 bytes...Meaning that is should be 3568 bytes but I don't know to how to remove that extra information in the file that rounds it up.
    Attached Files Attached Files

  38. #29
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    688
    Thanks
    41
    Thanked 174 Times in 88 Posts
    3977 for usual version and 1810 for experimental one.
    Usual version has no performance drop comparing to yours. Experimental should work ok for any system. By the way what does your "The 1688 byte version does not work" statement means? Any failed attempt to run some executable is logged in Windows event system. Please provide a detailed info about this issue.
    Also. You have additionally modified the sources of Crush by replacing some functions with WinAPI equals but you didn't mentioned it. Why?
    Attached Files Attached Files

  39. #30
    Member
    Join Date
    May 2012
    Location
    United States
    Posts
    343
    Thanks
    200
    Thanked 58 Times in 42 Posts
    Quote Originally Posted by Skymmer View Post
    3977 for usual version and 1810 for experimental one.Usual version has no performance drop comparing to yours. Experimental should work ok for any system. By the way what does your "The 1688 byte version does not work" statement means? Any failed attempt to run some executable is logged in Windows event system. Please provide a detailed info about this issue.Also. You have additionally modified the sources of Crush by replacing some functions with WinAPI equals but you didn't mentioned it. Why?
    When I said it did not work I meant that it would not decompress a file. It would stall for a few seconds and produce no file. Also, I did not modify the source. If modifications occured, the compiler did it. I don't know what WinAPI is. My kmowledge of programming is non-existent.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •