| |
Bitbreaker
Registered: Oct 2002
Posts: 498 |
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....
|
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting BitbreakerWhat else matters? Size (resident that is)? Disk usage? Compatibility? Of course, speed is the most important measure in the end for top-rated demos. But yes, compatibility and arcane things like "ease of use" do matter as well, in other contexts.
Furthermore, every top-notch group will end up rolling their own loader sooner or later, if only for "not invented here" reasons to dismiss other solutions. Everybody else chooses some existing loader, and then decides which one to use on many factors. Speed not being that important any more because there is less requirement for it compared to the latest iteration of colour cyclers/sample replay/blocky video. :)
That said, you still haven't added version numbers in your stats.
Oh, and i don't quite trust those numbers. I've been getting around 3.5-4 kB/s raw transfer speed for years (of course under optimal conditions, which i'm sure you also keep a close eye on for the number dearest to you), and yet i see significantly lower numbers in your graphs.
I also think the numbers should be separated for the four track zones, with some (weighted) average to boil them down to one number in the end. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 498 |
Quoting KrillOf course, speed is the most important measure in the end for top-rated demos. But yes, compatibility and arcane things like "ease of use" do matter as well, in other contexts.
Furthermore, every top-notch group will end up rolling their own loader sooner or later, if only for "not invented here" reasons to dismiss other solutions. Everybody else chooses some existing loader, and then decides which one to use on many factors. Speed not being that important any more because there is less requirement for it compared to the latest iteration of colour cyclers/sample replay/blocky video. :)
That said, you still haven't added version numbers in your stats.
Oh, and i don't quite trust those numbers. I've been getting around 3.5-4 kB/s raw transfer speed for years (of course under optimal conditions, which i'm sure you also keep a close eye on for the number dearest to you), and yet i see significantly lower numbers in your graphs.
I also think the numbers should be separated for the four track zones, with some (weighted) average to boil them down to one number in the end.
Feel free to do so! |
| |
lft
Registered: Jul 2007
Posts: 369 |
Krill, your loader is an exemplary piece of engineering. It is highly configurable and supports a multitude of use cases where regular files or IFFL are desirable. 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.
Quoting Krillyou still haven't added version numbers in your stats.
For my graphs, that would be Spindle 2.0 and Bitfire 0.3.
Quote:I also think the numbers should be separated for the four track zones, with some (weighted) average to boil them down to one number in the end.
This is a good idea. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
let's not forget that bitfire is a mod of krill's loader, which is the most used loader ever and was amongst the fastest (if not the) until a year ago or so. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 498 |
Quote: let's not forget that bitfire is a mod of krill's loader, which is the most used loader ever and was amongst the fastest (if not the) until a year ago or so.
A mod? Krills loader was a very good example of a working loader, that is why i used it to learn how a loader works in detail. Of course i also lend ideas and codesnippets, but also from other loaders like polish loaders and also from the first spindle version. There's no need to reinvent the wheel for things that are common knowledge. I wanted to get the concept of a predictable sectorchain (with 256 bytes payload that is) to run and see how it would perform. Also i wanted to have a way smaller resident loader part. Nevertheless, i wrote the whole thing from scratch and evolved from there and shrunk code from there and also replaced a lot of stuff with own routines, as they allow for more tolerance, or are smaller or faster.
So have you ever looked into the code and have compared? The only similiar things might be the checksumming and slight parts of the gcr decoding, transfer. Really, this bitching starts to piss me off.
Also, it is not my fault if krill has no time to improve his loader, i preferred to do my own then before waiting for years. There's no need to doubt in the need, stuff like the huge gfx scroller in comaland would not be possible with a slower loader/depacker combination, as the next pic would not arrive in time (it is going in 50fps, not the usual 25).
Also, here's an updated benchmark for krill's loader (#146 that is) disk written with an interleave of 5 and loadraw as example. $5e9 (see @ $0959 after loading finishes) frames is what i get so not much difference but slightly better. 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.
penis.d64
</rant> |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
"i wrote the whole thing from scratch .. and also replaced a lot of stuff with own routines"
o really? :)
"Submitted by Krill [PM] on 27 October 2014
Dr.j: As far as i understood it, Bitbreaker took my loader, removed everything not strictly needed by a demo "
also looking at someone else's source code and taking over ideas hardly qualifies as "taking over some common knowledge" in my book. sounds like everyone and his dog could write a loader. Without krill's source you wouldnt be able to make bitfire or it would have taken 10x as much work. So give credit where its due. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
lol |
| |
Bitbreaker
Registered: Oct 2002
Posts: 498 |
Sorry, i did line vectors, filled vectors and all other kind of stuff recently. I guess i also forgot to give proper credit there, as i am sure others did those effects before me and i might have done things in a similiar manner. I guess i shamelessly copied everything there too and just removed the unnecessary stuff to make it faster. m(
Have you compared the fucking source meanwhile or do you prefer talking more bullshit?
The real mod is in bitnax, where i picked up doynax source and adopted it to my needs. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
try looking at the source? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
