[ DWR | DocTree | Blog ]
<< Killing Blog Spam without Captcha | Home | Which Conference? >>

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.

Cringley 2007 Prediction 5:
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.

Tags :
Responses[7] RSS feed for responses to this blog entry
Posted by Joe Walker on 23 January 2007 20:48:33 GMT #


Reply

Re: The Hardware of Tomorrow Versus the Platform of Tomorrow

Comment from Frederic Jean on 23 January 2007 22:49:12 GMT #
This is partly why I think that platforms that focus on multi-process computing rather than multi-threaded computing will have an advantage (at least on the server side). I have seen too many projects struggle with thread-safety and concurrency in Java EE code to have much faith in the developers ability to leverage multi-threading. This is where LAMP and Ruby on Rails have an advantage: since each request runs in its own memory space, there is a lot less room for errors.
Reply

Re: The Hardware of Tomorrow Versus the Platform of Tomorrow

Comment from Neil Mix on 24 January 2007 16:01:18 GMT #
I agree that the ultimate solution to this problem needs to be at the language level. I'm wary of Java-style concurrency, though, as it's extremely complicated and nearly impossible for mere mortals to get right. There have been advances in concurrency design since Java was invented, languages like Erlang that allow for coding in a single-threaded style while parallelizing multiple "processes" for concurrent execution. In any case, the JS2 design affords little in the way of concurrency and nothing in the way of parallel execution, so I suspect we're going to be living without parallel execution in the browser for a looong time.
Reply

Re: The Hardware of Tomorrow Versus the Platform of Tomorrow

Comment from Kris Zyp on 24 January 2007 18:49:01 GMT #
To understand the difference in threading needs between Java and JavaScript it is important to think about their different usages. One of Java's main usages has grown to be for application servers (since applet's failure). In application servers, threading is critical, and Java's somewhat complicated, but robust premptive threading technology is very well suited for the environment. However, JavaScript runs in a browser, and so it is just running for a single user, there is no need to be concerned about other users. There are major programming advantages to a single threaded machine. There are a quite number of extra concurrency concerns when dealing with multi-threads (especially preemptive), and these concerns go away in single threaded environment, greatly simplifying programming, as well reducing bugs (and concurrency induced bugs are notoriously difficult to track down and fix, because they are often difficult to reproduce). Because so much code has been written and tested for single threads, if browsers were to allow multiple preemptive threads and trigger new threads on events (which seems like an obvious way to take advantage of threads), there would be a vast amount of code that would be broken becauseo of the ensuing concurrency issues. What Narrative JavaScript has introduced is form of threading that is cooperative. It is important to understand the distinction between cooperative threading (threads don't switch until they give up control), and preemptive threading (threads are switched by a timer in the OS). Preemptive threading is very important when dealing with multiple threads that need to compete for resources. This is essential for the OS when dealing with multiple processes and for application servers handling multiple users. However, preemption is not nearly as important in a single application when a programmer has full control of when threads release control. Therefore cooperative multitasking is very well suited for the browser. In addition, many (not all) of the concurrency issues go away with cooperative threading, because as programmer can be certain that thread switching will only take place in known situations (on calls to functions that can yield/suspend), instead of at anytime as with preemptive threading. This gives a much more predictable situation and greatly reduces concurrency issues. I am a big fan of Narrative JavaScript, and my project Authenteo is built on Narrative. I use multiple cooperative threads extensively in my project, and think it is amazingly powerful. My system uses a rendering/templating engine which makes Ajax calls to collect data as needed to perform rendering, and can split off into multiple threads as needed to do this. It is really comes together very powerfully, and Authenteo provides a development environment for writing multi-threaded JavaScript applications. Also, you can see the power of threading in my animation article which was on Ajaxian a couple weeks ago. One growing concern, I do see, is that hardware is definitely moving in the direction of multiple processors, which requires multiple (true, not cooperative) threads to take advantage of. Browsers are certainly not taking advantage of multiple processors right now, and as I mentioned, that can't without breaking a lot of stuff. However, It may be possible for browsers of the future to perform certain tasks in other threads, like the actual visual rendering of the page, without side effects (I believe different browsers do this at different times even now).
Reply

Re: The Hardware of Tomorrow Versus the Platform of Tomorrow

Comment from Anonymous on 28 January 2007 18:37:37 GMT #

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.

Not a solution: on top of the point you're raising, most of the javascript code out there is pretty much the lowest of the low as far as quality goes (the majority of the javascript "coders" wouldn't have the ability to use threads in the first place, not with the current JS semantics anyway)

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.

I don't see any reason for that not to work either, but even if it did actually work the only thing it would give the user is preventing the whole browser interface to freeze when a JS script runs amok, no load distribution here since the JS would stay single-threaded.

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.

Yep, even if the compiler tells you that it's spawning new threads, as long as it's running in a single-threaded environment (and therefore compiles your "multi-threaded" code to single-threaded code) I don't quite see the point.

The solution that I'd like to see is a language emerging that pushes the job of creating threads to the compiler

If that could easily be done in languages with mutable states, it would've been done already. That kind of stuff is already hard in languages using immutable structures/states, in highly mutable ones it's pretty much impossible.

that runs on the JVM, and that is available in all browsers.

And this does not compute as:

  • Microsoft is still the leader in browser marketshare, there's no way they're going to make MSIE depend on a JVM
  • Nobody wants to load a bloated JVM with its browser, applets' failure has already proved it
  • Even though some JVM-languages (Scala) have implemented sane/modern concurrency semantics (actors, akin to Erlang's processes + message passing semantics), most JVM languages -- and Java is at the forefront of them -- haven't, and I don't know the underlying JVM's concurrency semantics but I guess they mirror Java's. And we already know (well most people are discovering it right now, but the academics and the people who've been using massively parallel computing for some time know it) that Dijkstra's shared-memory & locks model doesn't work.
Reply

Re: The Hardware of Tomorrow Versus the Platform of Tomorrow

Comment from Ted Goddard on 31 January 2007 16:52:29 GMT #

The perspective of ICEfaces is that the browser plays the role of an event queue, just as in most user interface systems where the user is considered to generate a single stream of events (maybe this shouldn't be the case with multi-touch interfaces). The actual application runs in Java, hence can be multi-threaded. A reasonable application configuration would be to run the Java "server" application in a JVM on the user's local machine but still connect to it with a web browser.

Of course, this same technique could be applied with DWR, allowing the Java portion of the application to take full advantage of multi-threading.

Reply

Re: The Hardware of Tomorrow Versus the Platform of Tomorrow

Comment from linen on 31 August 2007 20:33:58 BST #
I see that as a very common problem with people looking towards the future. We are building programs and technology at different speeds. Right now, we are not using even the internet at it’s peak. There is a lot we could be using it for and the speeds that could come from the net are somewhere we have not even got close to reaching yet. We need to start shifting the focus to the hardware itself before we continue with these great advances in programming. If we do not start this pretty soon, we will have all these great programs and no one will be able to use them. We are getting pretty close to this point already. There is nothing worse than having something that you want so bad, and not being able to use it due to some sort of limitation.
Reply

Re: The Hardware of Tomorrow Versus the Platform of Tomorrow

Comment from baby on 04 October 2007 15:19:20 BST #
Very insightful, I must say. The truth is that there are new languages continously coming out, especially when we look at the web. This seems to have brought on many advantages : we are progressing forward, we are seeing a new resurgance of creativity, and companies like Microsoft are being forced to push boundaries along with everyone else, instead of just giving second rate stuff so that they can (in the end) make more money. However, the disadvantages are mixed standards and just too much to learn. The advantages can eventually become disadvantageous to us – and so it's interesting what's going on. And I don't think the hardware manufacturers are going to add much to helping at least in a long while.

Add a comment Send a TrackBack