I continue to fail to post weekly; all the fun stuff I would want to say, I don’t think I should talk about, though.
Anyway, the Opti compo is still going along, but it’s getting close to the end – right now there are 11 days before the compo ends. I’m adding this informational post to remind people and also to alert people to a new revision of the test system, better rules for whether an entry will be accepted or not, and various other things. I’ll reiterate the important parts on the competition page.
Firstly, the test system update: this update will probably be the final update of the test system code for this competition. Unfortunately I didn’t get all the stuff I wanted in it, I’ve been short on time and have had more than enough stress to go around :) So, this update does not contain the statistical time-sampling profiler that I wanted to add to the test app. It also doesn’t include a fractal explorer section which I had wanted to add. But on to the features that I did get around to adding: There is now a new default test set of 6 tests, they zoom in quickly on a specific point in the fractal, and are pretty complex areas to render (the number for max_iterations on the 6th image is 1400, and the horizontal and vertical steps are in units of 2^-44). I’ve included a modified example that is designed to serve as a lower bound for correctness – passing implementations should have a smaller amount of error than the lower bound. I don’t think this will be too hard, the lower bound currently exists as a modification to the multiply code that loses 3.5 bits of precision with each multiply. This actually caused less difference from the reference implementation than I had thought; currently across the 6 tests, there is a total difference of 7044 iteration counts, notably the 6 tests render a total of 147456 pixels, so this value is really barely even noticeable.
There was also a bug in the test app that caused it to only display the last test’s cycle count rather than the sum of all of them, this has also been fixed, and (in no$) the cycle count for the “lower bound” test is 0x0004CC483E1E cycles – which is 307 seconds of cputime, about 5 minutes. As the default test behavior also runs the example code alongside it, this means a test run of the lower bound takes about 10 minutes; not very good for repeated testing. I’ve added a way to start the tests without checking them, by pressing start instead of A, so the code execution time you have to sit through is purely your own fault ;) It will be pretty obvious if there are big errors, but it will still take a long time to check results against the reference function.
Ok, that’s all I have for now; I’ve been working on my own implementation just lately in assembly, but I really have no idea how well it will perform just yet. I’ll post some numbers in the comments on the Opti site once I get them.