[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-05 11:08

Oswald

Registered: Apr 2002
Posts: 5094

dont have hours to waste. anywas sorry for stirring this shit up. peace all. bitfire looks really cool, hope to try it out soon.

2015-07-05 11:17

chatGPZ

Registered: Dec 2001
Posts: 11386

lol

2015-07-05 12:35

Krill

Registered: Apr 2002
Posts: 2980

Quoting Bitbreaker

Feel free to give me hints on how to make this benchmark even faster, and then stop all that bitching and whining about a hurt butt already and work on faster loaders, smaller loaders, your next demo, so that there is no need anymore to complain about just a few groups dominating at the moment.

Was that directed at Oswald or me? Anyhow, will take a close look at it soon. And there's no butthurt here, as far as i can tell, and you're right about simply making new stuff rather than complaining. I was merely remarking about a perceived mis-representation.

Referring to credits and all, in Bitfire V0.1 there's a credit for me, and i'm fine with that. That case was closed a while ago. :)

2015-07-05 12:42

Krill

Registered: Apr 2002
Posts: 2980

Quoting lft

Bitfire and Spindle specifically address the modern fast-paced trackmo. I think everybody knows this, that we are trading genericity for speed, but it doesn't hurt to state it explicitly.

True. And i do not expect to surpass them in speed anytime soon (unless i come up with some new ideas), but be slightly slower, thanks to the "genericity overhead." :)

2015-07-05 12:52

Bitbreaker

Registered: Oct 2002
Posts: 508

Quote: its not that you're not the uncrowned kign of line routines, also i understand you did a LOT of work on bitfire, and giving away from free is a great move aswell. but from gunnar's and your reaction it feels you took most of his loader. thats not a problem. but sentences like "I rewrote it from scratch and even replaced some routines with my own" makes me raise my eyebrow.

I would have loved to have lft's on the fly gcr decoding implemented, but it turned out to take up too much mem in the floppy, so i first used the partial gcr method from the krill loader, in the following versions i then exchanged that part with new code that allows for more timing tolerance and decodes a bit more gcr bits in the inner loop. Protocol is standard 2 bit atn, so nothing new here for most loaders. The main thing is, that pretty much things work very different to krill's loader, as i do not work by track/sector chains (just like lft as well), so i have 256 payload per sector what takes away a lot of complexity and pain, but brings other problems like the need of an own directory format, and thus also an own d64-image writer (We don't want to seek track 18 anyway all the time). Also the turn disk detection was easy to implement that way, avoiding the usual pitfalls with wrong disk-ids or flaky photo sensor code. The other stuff that i did similiar was the serialization of blocks on c64 side, in the yet unreleased version this is all offloaded to the floppy, as it is easier to set barriers there, the wanted sector list exists there and one can work on that, no need for an extra blockmap. From spindle 1 i used the stepping method, it looked slim but even that i managed to shrink. But the the stepping code is not much rocket science, i guess the hardest point is to get the gcr header and sector decoding done as fast as possible and without hanging on real hardware. It is not slapped together quickly, but developed over quite some time now. Take into account that i can invest pretty much time into demoscenestuff, and always have THCM at hand to test current images on real hw.
I hope this makes further clear that it is not just a mod, what i define as changes on already existing source. My favourite assembler is acme, it is the workflow i am used to and it is easier to do things from scratch, than modifying existing code anyway. All that said, if you ever happen to examine the code of bitfire (but also a look into krill's and the spindle code is worth it) you will notice that there's not much in common between krill's loader and the others, except the register sets of the VIAs and the gcr decoding scheme and sector read timings that one always has to cope with.

2015-07-05 13:03

Bitbreaker

Registered: Oct 2002
Posts: 508

Quote: Quoting lft
Bitfire and Spindle specifically address the modern fast-paced trackmo. I think everybody knows this, that we are trading genericity for speed, but it doesn't hurt to state it explicitly.
True. And i do not expect to surpass them in speed anytime soon (unless i come up with some new ideas), but be slightly slower, thanks to the "genericity overhead." :)

An as fast gcr decoding as done by lft but with your memory footprint would be the thing that would give the gain. I pondered a lot about it but so far the methods that manage that in one pass use pretty much mem for that (the loader used by BD as well, and it is most likely slower than krill's loader though, OOO wins as it seems).
As for the benchmark, let me know if i do anything wrong with the usage of your loader. For me that is the maximum that i can squeeze out on that penis.d64.
And yes, i share all the source and i am happy that all others do too. No need to read up things in binaries anymore. And i am happy if others get inspired by my or others achievements and try it even better. That is pretty much what all the demoscene is about, and it is the source of all the motivation put into it.

2015-07-05 13:16

Krill

Registered: Apr 2002
Posts: 2980

Quoting Bitbreaker

I pondered a lot about it but so far the methods that manage that in one pass use pretty much mem for that (the loader used by BD as well, and it is most likely slower than krill's loader though, OOO wins as it seems).

Interesting, but both techniques are not mutually exclusive, are they? Which brings me back on topic: in Spindle, GCR decoding is done on-the-fly, in one pass, alright - but checksumming still is done in a second pass, and while receiving the data on the C-64 side?

2015-07-05 13:20

Bitbreaker

Registered: Oct 2002
Posts: 508

Quote: Quoting Bitbreaker
I pondered a lot about it but so far the methods that manage that in one pass use pretty much mem for that (the loader used by BD as well, and it is most likely slower than krill's loader though, OOO wins as it seems).
Interesting, but both techniques are not mutually exclusive, are they? Which brings me back on topic: in Spindle, GCR decoding is done on-the-fly, in one pass, alright - but checksumming still is done in a second pass, and while receiving the data on the C-64 side?

Seems so, and what is a good thing, as it secures also the data transmission, if an error occurs there, the chcksum most likely also fails. Defenitely a win! the checksumming happens during transmission and the blocks get either acked or nacked on bad checksum. I calculated the gain/overhead if checksumming oon c64 side, as for my case it doesn't bring any gain but also no loss (speedwise that is)

2015-07-05 21:21

HCL

Registered: Feb 2003
Posts: 728

Common guys, give this guy some credit. He has obviously done a great job in drive code development.. Hmm, i'm talking about BitBreaker now, but the same goes for Lft of course :D.

Even if he looks at other's code, and even uses it, i have to admit at this point that i do that as well! Looking at other's code is probably what inspires me the most, sometimes it gives me an idea of how to do it better, and perhaps i do it. It's only every now and then that i come across something original, like rotating rasterbars or such.. that i can really take the full credit for myself.

Then i guess we do have a problem with how this guy expresses himself, i do at least.. He is yelling a bit more than some others, he uses genital words alot, and he seems to like being in the spotlight. FUCK HIM for that :E, ok so now we can just calm down and try to see what he is creating instead. Annoying also that he seems to have alot more time to spend on this thing, that we all could easily spend a 50% occupation on :).

Now what was this thread about again!? Spindel 2.0?? Never heard of it ;)

2015-07-05 22:02

Danzig

Registered: Jun 2002
Posts: 440

Finalizing this thread:

* you are all dumbfucks, 'coz you use software for development coded by others (Turboassembler, Acme, Kickassembler, ..). please go back and use basic with read and data for generating your assembler code :) only using basic is valid because it's build-in!
* you are all dumbfucks, 'coz you peek in other peoples code. this is not the right thing to do! exception: there is a license like lgpl granting permission. Otherwise you are one foot in jail. Really!
* you are all dumbfucks, 'coz you run up the hill instead of keeping calm. Oswald trolls and you all step in the trap.
* you are all dumbfucks, 'coz Bitbreaker compares penis and you all step in the trap.
* you are all dumbfucks, 'coz every researcher starts from ground zero. Always! Ever! I promise!

You see, it's not pretty easy in 2015 to get the reputation you want when working with aces like Axis, Bob and THCM :)
Tobi, you've gone places! You deserve where you are.

You see, it's not pretty easy in 2015 to accept the reputation you got when your loader is aging. :)
Gunnar, you're still there! Your work is awesome and we love you.

You see, it's not pretty easy in 2015 to keep trolling high level when the last meme containing your name is unposted for years. :)
Oswald, you're a still strong within the trolling force. You should better code some new demo but still...

You see, it's not pretty easy in 2015 to stop commenting with 'lol' and 'rofl' even if you quit being mod. :)
Groepaz, you're still the most annoying but beloved scener there is. You have a place in our heart.

You see, it's not easy in 2015 to stop being amoused about all the rant and bitch fighting when your demo is still the best ever since X-2008. :)
HCL, you're you. And that is good. You will top yourself one day :D

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

Guests online: 112

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 Swappers

1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Violator  (9.7)
4 Acidchild  (9.7)
5 Cash  (9.6)

Page generated in: 0.055 sec.