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.
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.
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:
- Create a fast drawing program
- Build a real-time spell checker with wavy red underlines
- Warn users that they are going to lose their work if they hit the close box of the browser
- Update a small part of the display based on a change that the user makes without a full roundtrip to the server
- Create a fast keyboard-driven interface that doesn't require the mouse
- 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.
Mark Pilgrim's book-in-progress Dive Into HTML 5.
Summary of What is new in IE 9 Preview