Welcome to our latest new user
! (Registered 2023-02-06)
You are not logged in -
CSDb User Forums
Release id #139611 : Spindle 2.1
Registered: Jul 2007
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.
Registered: Apr 2002
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.
Registered: Dec 2001
i think the difference is doing it vs not doing it :=)
Registered: Jan 2003
Oh, so these CSDb threads actually can be useful... ;)
Registered: Aug 2010
My thoughts exactly Mr. SID
Subscribe to this thread:
You need to be logged in to post in the forum.
Search the forum:
CSDb Bug Reports
CSDb V2 development
Messages to moderators
Writer & text
All times are CET.
Guests online: 36
Edge of Disgrace
Coma Light 13
Uncle Petscii Presen..
The World Is Not Eno..
Top onefile Demos
Barry Boomer - Trapp..
Daah, Those Acid Pil..
POKE 56576,1 for Unl..
No Mercy for the Tro..
2 shades of Gray
Copyright © No Name 2001-2023
Page generated in: 0.052 sec.