Why Personal Supercomputers?

I’ve known for a long time that I was made to build fast computers. This passion for speed covers several areas of my interests but it is in computers where I have the most ability to contribute to creating the fastest machines. However what I’ve learned in the last few years is that the value of fast computers is limited unless they are accessible to a wide-range of people. This is why making the computers I build for the Raiden project something any programmer could own is a keystone of the work. I’ve written before about how having a computer of my very own at a young age had a fundamental effect on my life. The reason this was even possible was due to the personal computer revolution which began not with companies like Apple, Commodore, TI, etc. but with curious and tenacious hackers building machines in their basements and garages. They saw the potential in the overgrown calculator chips (which we call “microprocessors”) that the contemporary computer industry regarded as toys and they cobbled together machines out of the materials they had available. They didn’t do this because they had a grand vision of how these “microcomputers” would eventually push the industry leaders out of the market and herald unimaginable new applications, they did it because it was cool, and the rest flowed naturally. I want Raiden to follow a similar path. I’m not building Raiden for a specific application, I don’t have something particular in mind as I go along. Personally, there are a number of things I want a computer like this for myself, but I want to make sure I’m designing the system (both the hardware and the software) in a way that is open and flexible, making it something others can hack into whatever form suits their yet-to-be-imagined applications. I want Raiden to be something you can own, but I also want it to be something that can scale beyond the kind of power that would be practical to own yourself. This dynamic scalability is a promise “The Cloud” has made but for many reasons has failed to provide, and of course the cloud has no provisions for actual ownership. How I plan to address this seeming paradox is to make collaboration a core component of Raiden’s operating system. The scale and cost of an individual Raiden computer is designed to be something almost any programmer can afford, and its built-in participation in a global network of Raiden computers is what allows an individual programmer to scale their application far beyond the capability of their own hardware. Participation in this network is not mandatory, however it will be rewarded by providing network access “tokens” to owners who allow their systems unused cycles to become part of the global pool. This means that when you’re not putting your Raiden computer to work, you can be earning credit on the global network to use when your own programs are ready to do more work than your personal Raiden system can handle. Since this is intrinsic to the operating system Raiden’s development tools can tell you when you’ve reached this point and accurately estimate how much network credit a given job will consume (how this works and why it is critical is something I’ll save for a future post). In addition to earning credit through lending unused computing power, Raiden may also generate credit when you run your own jobs on your own system. The purpose of this is to encourage programmers to invest time learning to use the system and explore ways to maximize the potential of the hardware. I believe this balance of both unfettered access to one’s own personal supercomputer and uncomplicated access to a globally distributed, federated cluster allows Raiden to provide the advantages to programmers which the first personal computers lent to my generation, while at the same time providing a scalable platform to run the applications these programmers develop at scale. The incentive mechanism provides benefits to programmers who actively work on applying Raiden to problems or passively participate in supporting other programmers work without providing unfair advantages based on a social, political or economic basis. A side-effect of this approach is that it may also encourage “enterprise” participation in the Raiden network. The reason for this is that the ability for idle hardware to earn network credit might offset costs in a way that competing systems may not. There are numerous advantages to distributed, federated systems which apply to this architecture but which I won’t enumerate here (they are thoroughly treated elsewhere). What is important to note is that these advantages are intrinsic to the system described above and serve to extend the list of advantages to the approach described.