The Hardware of Tomorrow Versus the Platform of Tomorrow
It seems to me that there is a problem. The OS/platform of tomorrow is not designed to make good use of the hardware of tomorrow.
The Hardware of Tomorrow
In 2003 the hardware race was about GHz, and the clock wars. AMD and Intel competed on their clock speed, and people checked off clock speed advances against Moore's Law. In 2006 the battle lines began to be re-drawn around cores rather than clocks; Dual Core became the norm for new processors, and the next generations of chips from both AMD and Intel will be steadily increasing the number of cores. Intel and AMD have slightly different strategies, Intel is going for more generalized processing units, AMD (having bought ATI) are choosing to make their processing units more specialized.
So the hardware of tomorrow is going to work best with software that encourages multi-threading. Java's memory model and util.concurrency make it technically strong, and Billy Newport thinks that framework developers will need to alter their APIs to take advantage of the threads. He's probably right, but I suspect that to do a proper job, we're really going to need a language that builds multi-threading in at a lower level, leaving the compiler with the job of creating multiple execution paths. However that's not going to be quick.
AMD and Intel continue to beat the crap out of each other with customers gaining but wondering why there is no software that supports those new 8-way processors, as both compilers and third-party developers fail to keep up.
Knowing this, Cringley's 2007, prediction #5, is a bit of a no-brainer.
Today, even just dual cores, one core spends a lot of time idle. Anyone spending any time waiting for javac to do it's work will be wishing it did a better job of using more than one processor. The "multi-threaded is hard" problem is one of the things killing the PS3 now. The PS3's cell processors seem to be too advanced for most of the games manufacturers right now.
So if the hardware of tomorrow is going multi-threaded, what about the platform that developers use to write software?
The Platform of Tomorrow
I don't think we are in for any radical changes in platforms in the next few years. We'll continue to have a mix of Windows on the corporate desktop, Linux in the server room, and MacOS for developers, and arty types, and none of them being the primary development platform, which will continue to be the web.
The web is the default place to develop new software these days. If you need raw speed, hardware access, 3D, off-line usage or top-quality OS integration, you'll use something else, but for everything else there's the web.
The problem is that web-browsers are a step backwards as far as multi-threading goes. In Javascript there is no such thing as a new thread, and worse than that, the entire platform (i.e. a browser) runs a single JavaScript thread. If a script in one window goes into a tight loop, or runs some synchronous Ajax then the browser HTML display freezes.
So are the any solutions?
- Adding thread primitives to Javascript might technically possible, but it seems to me to be impractical; the single-threaded assumption is built fairly deeply into many applications.
- It might be possible for browser manufacturers to create a thread per domain. I don't see how this could cause problems, but I'll admit that I have a suspicion that I'm overlooking something. If it does work then it might be possible to allow developers to create new threads by dynamically creating iframes in other domains and having some safe way to communicate between them.
- There is a Javascript pre-compiler called Narrative JavaScript that looks like it might be of some use: it contains a
spawn()method to start a new thread of execution. It's written in Javascript so you can deliver the pre-compiler to the browser or deliver the output. However until there is support for something like this at a language level that can exploit newer hardware, it doesn't solve the problem.
The solution that I'd like to see is a language emerging that pushes the job of creating threads to the compiler, that runs on the JVM, and that is available in all browsers. I think I can safely predict that this is not going to happen any time soon though.
So maybe the biggest challenge to Ajax is that compared to desktop applications they are going to look slower and slower as other platforms are quicker to embrace tomorrows hardware.