- The Language Barrier
- Compiler Cleverness
- Evolving the Language
- Future Challenges
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Future Challenges
At the moment, CPU and GPU code are generally separated in a program, for these simple reasons: Both CPU and GPU have their own (local) memory. Also, while both are fast, copying between CPU and GPU is expensive.
This relationship is likely to change over the next few years. Just like floating-point coprocessors before them, GPUs are being moved onto the main CPU die. This has already been the case in mobile systems-on-chip (SoC) for a while; they typically include a few different processing units, such as an ARM core, a GPU, and a DSP, on the same die. Most importantly, they're behind the same memory controller. Therefore, much less cost is involved in distributing work between the CPU and GPU. Rather than needing to copy data across a PCIe bus to the GPU, work on it, and then copy it back across the bus, these systems just need to update some page-table entries.
When systems like this become more common, even offloading relatively small code segments to the GPU will be advantageous. Some of this work can be done with existing languages, but for best results you'll want something designed specifically for that purpose.
Unfortunately, OpenCL isn't the solution. Because it's designed entirely around the copy-execute-copy model, it adds a lot of overhead (in terms of source-code complexity) if you don't need the copy. For low-level programming, expect to see languages like C introduce something like futures. These are already in the C++0x specification, making it trivial to implement asynchronous calls, synchronizing when you try to access the result.
With this style of programming, you can call a function that will run on a coprocessor, do some other work, and then wait for the coprocessor to finish (if it hasn't done so already) when you need to use the result.
From the mid 1970s, processors have continued in a relatively simple evolutionary path, providing little incentive for languages to adapt. Multicore and heterogeneous systems, which have become increasingly common over the last few years, change that situation. The next decade is likely to be an interesting time for language designers.