[CSDb] - User Forums - Release id #139611 : Spindle 2.1

You are not logged in - nap

CSDb User Forums

Forums > CSDb Entries > Release id #139611 : Spindle 2.1

2015-07-08 00:55

lft

Registered: Jul 2007
Posts: 369

Release id #139611 : Spindle 2.1

Recently Bitbreaker posted some interesting data on the performance of various loaders (Release id #139503 : Spindle 2.0). What I found particularly eye-opening was the way the performance drops linearly as the CPU load increases. This means that our loaders are, primarily, CPU bound. And this is important, because in a reasonably fast-paced trackmo, the loader will always be sharing the CPU with some ongoing effect.

As far as the loader is concerned, the (C64-side) CPU is doing two things: Receiving serial data and decrunching. In Spindle, the serial transfer loop is about as tight as it can get, at least with a reasonable memory footprint. But I thought that perhaps the decruncher could be improved.

I tried a number of different approaches, some quite elaborate. But in the end, of course, the only thing that worked was a simple design and a bunch of crazy optimisation tricks. Check the source code if you dare. =)

Crosses are Bitfire 0.3.
Hollow circles are Spindle 2.0.
Green circles are Spindle 2.1.

For this dataset, the best case loading time (i.e. at 0% CPU load) is 1121 frames, for an effective throughput of 8.2 kB/s, compared to 7.4 kB/s for Bitfire 0.3.

The effective rate depends on how well the dataset can be crunched. It would be nice to get this cross-checked on a different dataset. Still, I think the plot gives an accurate picture of the relative speed of the loaders.

These measurements were made with vice, but I've gotten similar results on real hardware.

There's an additional neat trick that I included in Spindle 2.1, which I expect is mainly useful on real hardware: Remember how Spindle uses scripted loading, so it knows what you'll be loading next. Right after a loader call returns, the drivecode prefetches a sector from the next file, before turning off the motor and awaiting further instructions. When the next loader call arrives, the sector is already in the buffer, ready to be transmitted. Here's the novelty: When that call comes, Spindle 2.1 will warm up the motor. That is, the motor is spinning up while the prefetched sector is being transferred, in anticipation of the next (pre-)fetch.

While the prefetching mechanism already reduced the effective time of each loader call by one sector-fetch, this technique further reduces it by one serial-transfer. All thanks to scripted loading.

2015-07-08 02:07

Krill

Registered: Apr 2002
Posts: 2980

Maybe i'm missing something, but where is the advantage of "scripted loading" when files in a typical demo are loaded in linear ascending order with regard to the directory, anyways?
You can pre-buffer the next file's first block and do some motor spin-up just fine when assuming that the next call will load the next file in the directory. The cases where this is not so are probably rare.

2015-07-08 05:49

chatGPZ

Registered: Dec 2001
Posts: 11387

i think the difference is doing it vs not doing it :=)

2015-07-08 08:08

Mr. SID

Registered: Jan 2003
Posts: 424

Oh, so these CSDb threads actually can be useful... ;)

2015-07-09 21:25

Scarzix

Registered: Aug 2010
Posts: 143

My thoughts exactly Mr. SID

Refresh

Subscribe to this thread: