I have spent this week at NVIDIA's GPU Technical Conference in San Jose. It has been thought-provoking for me; I had not realised the extent to which GPU programming is taking off.

By GPU programming, I do not mean creating games or cool graphics in DirectX or OpenGL - though in practice many applications involve some graphical elements - but using the GPU for general-purpose programming.

Why bother? Simply because for certain kinds of processing, the performance benefit is spectacular. It is easy to demonstrate. At the exhibition here, Jedox was demonstrating its Palo GPU Accelerator. The demo involves a business intelligence analysis in Excel that when running normally in Windows, takes several minutes to compute. Use the accelerator instead, and it is instant. Note that the accelerator is not normally on the same machine as Excel; in fact, you can have a GPU-based high performance server on a network and share it with multiple clients.

The technical reason for this high performance is that GPUs specialise in massively parallel processing. Whereas in CPUs havng 2, 4 or 8 cores on a system is common, an NVIDIA Tesla GPU starts at 240 cores, and you can put up to 8 in a single box. Teslas are GPUs that cannot drive a display; they are intended purely for GPU programming. You can also code against standard NVIDIA GPUs like Geforce. GPUs are not an alternative to CPUs, but as specialist number-crunching add-ins they are remarkable.

What is also interesting is that whereas CPU performance improvements have slowed thanks to technical issues such as limits on how far clock speed can be increased, GPU performance is still marching ahead. The parallel approach is more scalable, and because it does not depend on increasing clock speeds, more power-efficient. This means that the value added by GPU programming is likely to increase in the coming years.

The scientific, engineering and academic community has jumped on the GPU bandwagon since it brings significant benefits to their work. This has been evident at the GPU conference, where the floor is lined with posters summarising interesting GPU programming applications.

While the advantages of GPU programming are real, the supporting tools are still somewhat challenging. The most common approaches are either OpenCL, which works across GPUs from multiple vendors, or CUDA C, extensions to the C/C++ languages that let you execute code on the GPU and copy memory between the GPU and the main system, but which only works on NVIDIA GPUs. Although the OpenCL standard is attractive because it runs on more systems, CUDA C is widely used in scenarios where you can specify the hardware. Either way, you need to grok concurrent programming and the subtle bugs it can introduce. It will never be trivial, but there is work going on to bring GPU programming to more languages, such as Python and Microsoft .NET, as well as libraries to simplify managing memory across what is in effect a computer within a computer.

This week's conference has convinced me that GPU programming is something any developers need to be aware of. Where it goes from here will be interesting to watch. NVIDIA deserves credit for advancing the field, but faces competition from AMD, Intel and others. I would also expect the standards-based OpenCL approach to gain in popularity, though the word here is that it is not quite mature enough yet. Finally, NVIDIA is insistent that this is not just for the high-end, but that we will see GPU programming at every level from cloud to desktop to mobile device.

If you are using agile or lean to manage your work, you are limiting work in progress. Agile limits work in progress by timeboxing--if the work doesn't fit into the timebox, you don't start it. Lean limits work in progress by limiting the number of items in any given state (started, in development, in testing, whatever).

When you limit work in progress, you give yourself a chance to finish one thing at a time. We, as human beings, are better at finishing something and going on to the next thing than we are at having many pieces underway. We miss problems with lots of work in progress. We are more likely to see problems when we finish (as well as we can) a given piece of work for now. If we have to return to it to make things better later, that's ok.

You can limit the work in progress regardless of the kind of project you have. If you are starting a serial lifecycle, explain that you want to finish the highest priority work first and then move to the next batch of work. You may have to ask the requirements people to timebox their work on requirements so you can move on to analysis and design. But even if you can't change the front of the project, there is nothing to stop you from implementing, integrating and testing as you go, once you are in development. Even in a serial lifecycle, there is no law against continuous integration!

Now, you and I both know that it's no longer a serial lifecycle if you start integrating and testing as you develop, but that's ok. Your customers, managers, and other stakeholders will be happy you did.

My experience, and I'm sure it varies from yours, is that once your stakeholders see the documents for requirements and architecture don't care much about your functional specs or other documents, such as design. Those documents are for the technical people. So if you must, start a project with a serial lifecycle, and then move into prototyping so you can understand the architecture, or, at the least, move into delivering chunks of work.

The lifecycle of "get some requirements, decide on an architecture, implement by feature, integrating and testing as you proceed" is an incremental lifecycle called staged delivery. It's a great way to limit work in progress and see your project state as you proceed. It's not strictly serial, but it works. And, isn't that what they pay us to do?

The results are in, and the signs aren't good. According to the Joint Council for Qualifications, the number of students taking the GCSE in ICT dropped by 17% this year, compared to 2009. A-level students fared little better, with a 13.7% drop in those receiving computing-based qualifications this year.

My first real encounter with what we loosely call "HTML 5" was nearly three years ago, at a 2007 Future of Web Applications conference in London. Mozilla's John Resig showed features including the Canvas element, SVG, video and audio. I reported on it here, noting that it might be too late to disrupt the momemtum behind Adobe Flash and Microsoft Silverlight.

I would not have guessed that in 2010 Microsoft itself would demonstrate a version of Internet Explorer with support for these features. I'm referring to the version 9 fourth platform preview, which you can try out here. In case you missed it, the new IE scores 95% on the Acid 3 CSS stress test (and the other 5% is unimportant), performs creditably on the SunSpider JavaScript performance test, being more then ten times faster than IE8, and implements significant parts of HTML 5 including Canvas, SVG, Video and Audio.

It is true that HTML 5 as a standard is messy and incomplete. It will be many years before it is done. That said, key features of HTML 5 will be ready much sooner; in fact once IE9 appears we will be able to say that the latest versions of all the major browsers support them. This includes WebKit, which is used in many mobile browsers as well as in Apple Safari, Google Chrome and Adobe AIR, so parts of HTML 5 will work on mobile devices as well as on desktops.

The implication is that we need to rethink, again, what are the limits of browser-hosted applications even without plugins. Here's Joel Spolsky writing six years ago:

Here are a few examples of things you can't really do well in a web application:

1. Create a fast drawing program
2. Build a real-time spell checker with wavy red underlines
3. Warn users that they are going to lose their work if they hit the close box of the browser
4. Update a small part of the display based on a change that the user makes without a full roundtrip to the server
5. Create a fast keyboard-driven interface that doesn't require the mouse
6. Let people continue working when they are not connected to the Internet

Interesting to read this now. Of these, it is really only the last, offline use, that is still a major problem. There is some provision for it in the HTML 5 specifications, but this is not an area that is widely implemented yet.

It is more fun to consider what you can do in HTML 5, including high-performance graphics and code. Developers are beginning to push the boundaries. James Pearce, for example, has a work in progress that shows how the BBC could have implemented its iPhone/iPad news app in HTML 5 - it is not perfect yet, but it is making a point: why make an app that only runs on Apple devices, when you can do the same thing for the open web?

The support in Internet Explorer 9 is significant, partly because Microsoft still claims the biggest market share in web browsers (though not in Germany, where FireFox has nearly 60% share according to StatCounter), and partly because Microsoft-platform businesses both have a disproportionately high usage of IE and are an important market for developers of custom software.

Let me emphasise: I'm aware that IE9 is still in preview, and that even IE6 still has significant usage in some quarters (though only 4% worldwide, again according to StatCounter). I'm also aware that HTML 5 application development tools are in their infancy, and that plugins like Flash and Silverlight offer more predictable results as well as middleware support and a full suite of mature development tools. Plugins are essential for real-world use in many scenarios. It is possible that this will always be the case, that as HTML 5 advances the plugins will simply leap further ahead.

Looking ahead though, it now seems likely that native HTML, CSS and JavaScript will grow in importance as a viable client application platform. At the very least, I'd encourage developers to try out the IE9 TestDrive examples, or equivalents for other browsers, and glimpse a future where zero-deployment, true cross-platform, and full web integration come together.

Further reading

Mark Pilgrim's book-in-progress Dive Into HTML 5.

Summary of What is new in IE 9 Preview