| |
Sparta
Registered: Feb 2017
Posts: 40 |
Loader Benchmarks
I do not intend to stir up the mud, but it’s been 5 years since the performance of commonly used fast loaders was last compared in this thread. Since then, Lft has updated Spindle, Krill has practically rewritten his loader, HCL has released ByteBoozer 2.0, Bitfire is past version 0.6, and I have released Sparkle (AKA “Chinese clone” :D, apologies to the Chinese sceners). I have been running tests for my own entertainment and figured I’d update Bitbreaker’s benchmark with the latest loader versions using his test files.
The graph below compares the following loader+packer combinations: Sparkle V1.4 and Spindle 2.3 using their own packers, Krill’s loader v184 with TinyCrunch 1.2 (TC), Bitnax (BN), and ByteBoozer 2.0 (B2), BoozeLoader 1.0 with ByteBoozer 2.0, and Bitfire 0.6+ downloaded from GitHub on April 9, 2020 with Bitnax. The sole purpose of this benchmark was to examine how fast these loaders can load and decompress 728 blocks of data in 18 files under different CPU loads (i.e. it does not test disk zones separately). I spent quite some time optimizing each loader’s performance as much as I could with preliminary trial runs in VICE with warp mode to find the best parameters. Thus, Spindle disks were built with the fast serial transfer protocol and in the case of Sparkle, Krill’s loader, Bitfire, and BoozeLoader, a custom interleave was implemented. Finally, the disk drive’s motor was left running during the tests with BoozeLoader and Bitfire. For each test I used the interleave that proved to be the fastest in the preliminary runs. All tests were performed the same way: the executable installs the loader and loads a small program from track 1, sector 0 (this way, seek time to track 1 is not included in the test) with a raster IRQ routine that blocks 0%, 25%, 50%, or 75% of the screen while loading and depacking. None of the files are loaded under the I/O area. Sparkle packed the files from 728 blocks to 442 (60.7%), Spindle to 456 (62.6%), TinyCrunch to 447 (61.4%), ByteBoozer and Bitnax to 390 blocks (53.6%). D64 images were transferred to the same floppy using Luigi Di Fraia’s IECHost connected to a 1571 disk drive. Each column in the graph represents the average ± 2SD of 10 consecutive tests on my C64C PAL + 1541-II disk drive combo (except for Krill+ByteBoozer in which case for some reason the test crushed 3 times requiring additional runs).
Interleaves (note: the files only occupy the first two speed zones on the disk):
Loader 0% 25% 50% 75%
Sparkle 4-4-4-4 5-4-4-4 7-4-4-4 7-4-4-4
Spindle default default default default
Krill 4-4-4-4 5-4-4-4 7-7-7-7 11-10-10-10
Bitfire 5-5-5-5 6-6-6-6 9-9-9-9 6-6-6-6
BoozeLoader 4-4-4-4 5-5-5-5 7-7-7-7 11-11-11-11
Feel free to interpret the data the way you want. Obviously, the authors of the other loaders and packers are way out of my hobby coder league, so I will not attempt to draw conclusions or pretend to have answers. But if anyone is interested, I’d be happy to share my test disk images and spreadsheets. Also, let me know if you want to see any other loader’s performance in the benchmark.
Finally, I am sure many of us do similar tests, so please feel free to post you own benchmarks with some description here.
Cheers, stay healthy and safe,
Sparta/OMG |
|
... 14 posts hidden. Click here to view all posts....
|
| |
Sparta
Registered: Feb 2017
Posts: 40 |
In the meantime, I am going to repeat the tests using your loader with the following additional specifications: test files will occupy the higher tracks (starting on track 35) and the first block on each track will be in sector 0. Additionally, with 0% CPU load, I am going to use interleaves 4-3-3-3. Please let me know if I understand it correctly or if you want to see any other optimizations. :) |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Hold your horses until i have a new build ready, at least for the ByteBoozer 2 test.
And i'm still surprised that it's generally not faster than loading uncompressed, so will investigate a bit more. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Oh, and the same drive should be used both for writing the disks and running the tests. |
| |
HCL
Registered: Feb 2003
Posts: 717 |
I don't like representing the brown column in those graphs, it's not my preferred choice of color and does not reflect to Booze Design in general. .. ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
nice to see the competetiveness still in you guys :D |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting HCLI don't like representing the brown column in those graphs, it's not my preferred choice of color and does not reflect to Booze Design in general. .. ;) Which of the 16 shades of brown we have on display is your preferred choice, then? :) |
| |
Sparta
Registered: Feb 2017
Posts: 40 |
Quoting HCLI don't like representing the brown column in those graphs, it's not my preferred choice of color and does not reflect to Booze Design in general. .. ;)
OK HCL, tell me the color of your Booze and I will... Never mind. ;) |
| |
HCL
Registered: Feb 2003
Posts: 717 |
Despite the brown.. It would be kinda interesting to see the compression ratio in this comparison. I guess the three to the left are all using crippled compression due to tiny search window, or? |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting HCLDespite the brown.. It would be kinda interesting to see the compression ratio in this comparison. I guess the three to the left are all using crippled compression due to tiny search window, or? OP did mention the compression ratios for this particular corpus.
And for tinycrunch, look here: https://codebase64.org/doku.php?id=base:compression_benchmarks - it's in the 60% compressed size cluster, while ByteBoozer 2 is in the 45-ish% cluster.
But for demos, compression ratio doesn't matter so much as overall throughput. Disk images are cheap. :D |
| |
Frantic
Registered: Mar 2003
Posts: 1633 |
Flipping disk( image)s when watching demos is hard work though. |
| Previous - 1 | 2 | 3 - Next |
