[CSDb] - User Forums - Release id #139503 : Spindle 2.0

You are not logged in - nap

CSDb User Forums

Forums > CSDb Entries > Release id #139503 : Spindle 2.0

2015-07-01 11:59

Bitbreaker

Registered: Oct 2002
Posts: 508

Release id #139503 : Spindle 2.0

So with the spin mode it was now easy to quickly do a speedtest with the files i usually test with (most of the files from cl13 side1).
It turns out that spindle nearly loads as fast as bitfire with on the fly depacking. While bitfire chews in the tracks a tad faster, it has to make breaks to finalize the depacking. So data arrives a bit too fast first and blocks pile up to be decrunched. Spindle manages to have a continuous flow due to its blockwise packing scheme here.
Therefore the 18 files used get squeezed down to 491 blocks, as with bitfire down to 391 blocks. So Spindle leeches an additional 100 blocks in about the time bitfire requires for additional depacking.
However, under load the speed of spindle turns down rapidly, with 25% cpu load it is no faster than krill's loader, with 75% load it takes eons to leech the 491 blocks in :-( What's happening there?!
When is the 50x version from Krill done? :-D HCL, what's the penis length of your loader? :-D

Results here.

... 91 posts hidden. Click here to view all posts....

2015-07-08 11:06

Bitbreaker

Registered: Oct 2002
Posts: 508

Not in the yet version, but that is what i do in the stream version prototype, having the disk filled with one huge blob, no partly filled sectors, every byte used. Then each block with destination address is fetched from that stream and placed in its respective place in mem. It is bound to in order yet, as no dir and no additional info is needed then. Therefore loading under IO is possible at no extra costs. Size is $131 + $100 buffer.
I btw. updated the numbers for spindle 2.1
Also did a test with huge files. Bitfire performs then at 9,10 kb/s, so it is true that huge files help. Loadraw performance is then at 5,67kb/s.

2015-07-08 12:42

Krill

Registered: Apr 2002
Posts: 2980

Linking all files to one is one thing, but do you also link before packing? :)

2015-07-08 13:44

lft

Registered: Jul 2007
Posts: 369

Quoting Krill

Okay, i'm sceptical about those gaps, but never mind. But then, would it be possible to have the compressor handle these gaps? Such that you'd link all the small unpacked files and compress to one big file in the end, with all the advantages of minimising loader overhead and maximising pack ratio.

Spindle already does that. When you specify multiple files for a loader call, they are packed end-to-end, with only a single half-filled sector at the end. If you use the pefchain interface, data is automatically split at page boundaries, a global loading schedule is created, and everything that goes into the same loader call is joined at the seams.

The only thing missing is the complete elimination of half-filled sectors, like Bitbreaker suggested. I've had this idea too, but haven't implemented it yet. But it's perfect for pefchain: Currently, all data is loaded as soon as possible, so data "bubbles up" to its earliest possible loading position, getting cut into pieces where necessary. This means that the data chunks will pass several potential loading spots on their way up through the schedule.

My idea is to keep track of all these spots, and mark a chunk as "optional" in any loading spot except its last one. When generating the combined file corresponding to a given loading slot, the cruncher first includes all the mandatory chunks, and then fills up with optional chunks. Afterwards, if the last block is half-filled, it may very well happen that this block contains only optional data. The block is then un-allocated, and the data that went into it is pushed down to its next loading slot in the list.

But, like I said, this is just in the idea stage at the moment.

2015-07-08 14:23

Bitbreaker

Registered: Oct 2002
Posts: 508

Quote: Out of curiosity... how does Mr Wegi's loader compare to these?

Bongo Linking Engine

I tried it, but i failed so far creating the .inc that contains all the labels so that i can at least address the files from main.asm or alike, and it comes with 32! different loadertypes, with t/s, dir, things, different packers, i'm lost. It seriously lacks documentation and a proper workflow :-( Whereas with spindle, you just smack in the 18 filenames into that script (and wipe out that sidfile being loaded there!1) and call loadnext() from the main file. That's it! While i'm no fan of loaderscripts in demos, i am with benchmarks :-D

2015-07-08 21:55

Danzig

Registered: Jun 2002
Posts: 440

Just for the sake of it, I would like to see f.e. BETA SKIP IFFL Mastering + Source compared to it. Just name the time used for scanning the iffl file. I would even not count it, since it's an initial process.

And what about file copy (possible? breaks the performance due to changing interleave or "3O"-order ?), random file access (like with a crack) instead of sequential access (demo)? Which system can not offer this features? I know, we are talking about trackmo loader systems, but isn't that narrow minded? Maybe lft and bierkeule can enlighten us, what would be the afford to get that feature and for what cost.

And as GRGs loader was already named, what about comparing with even more loaders (G.I. Joe ;) ). Just to draw a larger scale picture of what Spindle, Bitfire are really capable of. Benchmark is fine, but more reference values would rock. Hey Tobi, Du hast doch so viel Zeit ;)

Even compare it to patched kernal loader ($ee13 SEI moved so you just enter at $ee20. You just loose around 30 rasterlines per frame iirc).

jsr ee13_replace
...
ee13_replace:
LDA #$00
STA $A5
JSR $EE85
JSR $EEA9
BPL *-3
SEI
JMP $ee20

Of course, silly on the one hand, but maybe gives us all a brighter light of what we really have here!? And what other scenarios we might or not be able to realize with these systems.

Thanks for reading, no rant today ;)

2015-07-09 06:54

Bitbreaker

Registered: Oct 2002
Posts: 508

Ranzig, Du Troll!
It's all written in the results, below the graph is a list of features. Some can only load sequential (load_next) or by filename, others both. Others also can't load the raw file but only load and depack on the fly. Breakage of interleave can't happen due to the use of own d64-creators that support the somewhat custom format. However all still .d64 compatible and easy to copy with a bam copy or disk copy.
Now teach me to open the sideborder again and help me hugging street lights. If those loaders and toolchains are used for quality hacks there's at least the chance that you don't end up with a virus infection (oh wait, that was weasel who managed that). So give it a try!

2015-07-09 07:29

chatGPZ

Registered: Dec 2001
Posts: 11386

Quote:

Now teach me to open the sideborder again

AH! so that is where you stole your demo code!

2015-07-09 08:24

Danzig

Registered: Jun 2002
Posts: 440

Quote: Ranzig, Du Troll!
It's all written in the results, below the graph is a list of features. Some can only load sequential (load_next) or by filename, others both. Others also can't load the raw file but only load and depack on the fly. Breakage of interleave can't happen due to the use of own d64-creators that support the somewhat custom format. However all still .d64 compatible and easy to copy with a bam copy or disk copy.
Now teach me to open the sideborder again and help me hugging street lights. If those loaders and toolchains are used for quality hacks there's at least the chance that you don't end up with a virus infection (oh wait, that was weasel who managed that). So give it a try!

So, just take some iffl systems, add a row for "iffl" and "file copyable" and put them in compare. Those are also valid trackmo systems aswell. *G* Then I might stfu ;)

And maybe some newbie-friendly explanation so your benchmark can evolve to some reference f.e. to publish on codebase!?

sideborder: take the vic 1 register $9000 to move the screen to the left on even frames and to the right on odd frames. Toggle your bitmap accordingly and you got sideborder even with interlace. Ups, that was VIC 20 and that would look ugly. Hm, sorry, can't fulfill your request. Hugging street lights not possible either anymore, it would bend :D

2015-07-09 14:53

Bitbreaker

Registered: Oct 2002
Posts: 508

I did a codebase article about it. The inflicted persons may read up and correct/edit/add details if wanted.

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

kbs/Pht/Lxt
DJ Gruby/TRiAD
Guests online: 96

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)

Top onefile Demos

1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)

Top Groups

1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)

Top Musicians

1 Rob Hubbard  (9.7)
2 Mutetus  (9.7)
3 Jeroen Tel  (9.7)
4 Linus  (9.6)
5 Stinsen  (9.6)

Page generated in: 0.07 sec.