I read Viznut’s piece on “Permacomputing” last night and got all fired up. We do live in an age of unparalleled waste of computing resources. He is far from the first to discuss this – I recall Fabien Sanglard‘s and Derek Sivers’ polemics – but Viznut has the uncompromisingly ecological and long-term vision to contextualise and channel the typical hacker’s anger at wasted CPU cycles.
That made me think of my recent graphics-heavy work, using large resolutions and high-level frameworks; and of the kind of work I see myself doing long term: “coding ceremonial space, presence, substance and light”.
Frankly, I felt indulgent. I think Viznut is right: our civilisation needs to make drastic adjustments to save itself from ecological collapse. And although those changes are gonna be harder than a few well-intentioned Westerners turning to gardening, common sense and intuition and aesthetics and the environmental statistics suggest that permaculture and related ideologies – emphasising resilience, adaptation, local conditions and lowered resource use – may hold more solutions than our current dependence on growth.
When I read Viznut’s weighty opinions I wanted to do some work in the vein of his competition-winning computationally minimal art. Work that uses no more computing power than needed for the goal at hand.
Viznut and his ilk are so much more learned than I am, as coders. They specialise in low-level hardware hacking, an esoteric and difficult topic. However, one skill of theirs is more generally applicable yet fits precisely in the permacomputing ideology. As Viznut puts it, “Optimization/refactoring is vitally important and should take place on all levels of abstraction.”
So I’ll get technical now and chat about how I optimised my most recent learning project: “Iridesce”, a raycaster!
(In case you don’t know what raycasting is, it’s an old and simple way of rendering a maze from a first-person perspective. Windows 95 used it in an iconic screensaver, and it featured in 90s games, most famously Wolfenstein 3D.)
I used the profiling tool available in my browser, Slimjet (a clone of Google Chrome). This gives an indication of how much CPU time is spent on various aspects of running your site’s frontend code.
How did it go? Long story short, I was able to reduce 68% CPU usage to 20%! The things that worked were:
- Lookup tables – so, instead of calculating the rainbow colour function 400 times per frame, I save all possible values of it into an array and access that instead. This was the biggest single saving and is a pretty classic technique, whenever you have more memory than CPU available. I was also already using a lookup table for the angles of the raycaster.
- Using the HTML5 Canvas graphics API properly, in particular the ImageData objects which I was using to manipulate raw pixel data. Originally, from a vestigial memory of how raycasters are traditionally done, I was working with one-pixel-wide strips of data for every single segment of wall. This was entirely unnecessary and I saved a lot of CPU time by switching to a single large ImageData object covering the whole canvas. Incidentally, this necessitated some manual byte offset calculations, which felt pleasingly close to low-level.
And what didn’t have much effect:
- Tidying up to remove nested if statements and repeated checkings of the same condition. This improved the legibility of the program but I don’t think it did much for performance.
- Removing at least a dozen multiplications from loops. (Taking stuff out of inner loops is another classic optimisation approach.) I really thought this would make a difference, but I couldn’t see it in the stats.
So… the conclusion is pretty clear. Modern computers are stupidly fast at arithmetic. Manual low-level cleaning up doesn’t seem to change much. I’ll still do it for elegance. And I expect I’ll start seeing the performance benefits as I get better at implementing algorithms and doing my own profiling and benchmarking.
But more important than removing those multiplications and ifs, was checking which external functions are taking up time. Using the profiler I could spot that my colour calculations as well as the ImageData manipulations were actually taking up the most time. In both cases there was no need to call the function 400x a frame and I got massive improvements by fixing that.
So that was fun. Am I any closer to sustainable computing? A tiny bit.
Calculating byte offsets is getting into the realm of pointer arithmetic, a skill needed when programming simpler and older machines – increasing the range of systems I could do useful work on.
I learned about profiling and I did some quite major optimising, if mostly by fixing previous poor decisions.
And I got some clarity about what values are important to me, and a good dose of idealism. I’ll keep Viznut’s ideas of communally stewarded, resourceful not resource-intensive, locally appropriate, and aesthetic computing close to my heart as I decide how to direct my energies in projects and job-hunting.
There are other of Viznut’s ideas that I could elucidate through my own practice. How about developing the communal appreciation and understanding of technology in my own family home? Or working on feedback and visualisation of complex system state (I love interactive and live feedback from running systems and that’s how I tackle a lot of coding problems). Or the classic yet delicious challenges familiar from the 80s and 90s: making impressive graphics on slow processors! Perhaps even finding styles and tricks so that the imperfections of low-fidelity enhance the aesthetic affect.
Anyhow. Thanks for reading!