Yeah, that bugs me. I feel it should be one license per machine, but I can see how they want to make money. It’s also interesting how it relates to virtual machines.

Some other interesting things about virtual machines: When Microsoft release MS Virtual Server 2005 R2 for free, they also amended their OS licenses to allow you to run up to 4 virtual machines per existing license you own. That is, if you had a single license for windows 2003 standard, you could run 4 virtual machines and one physical instance of it. I thought that was pretty generous of them.

Platform support for multiple cores will also be interesting, as operating systems are not currently licensed per core but by physical processors. Thus an XP-Pro machine can use any number of cores, but a maximum of two physical processors (so, with quad core your XP-Pro machine can use 8 cores max). This type of licensing is probably going to change in the future to be parallel unit based, especially for server based operating systems.

Yeah, that bugs me. I feel it should be one license per machine, but I can see how they want to make money. It’s also interesting how it relates to virtual machines.

Here’s an old article on this:
http://www.networkworld.com/news/2004/071904multicore.html

Probably the most dramatic change in technology from a programmer’s point of view is the forced shift from single-threaded engines to multi-threaded ones. The next generation of consoles all have multi-core processors, and the majority of PCs aimed at gamers released from 2006 onward will have some kind of multi-core processor.

Yeah, much like modern business servers have had for years now (multiple processors at the least, which poses many of the same problems as multiple cores).

While a multi-core architecture is going to be the norm, the majority of game programmers are still unfamiliar with the techniques of multi-threaded programming. In addition, tools for debugging and profiling multi-core code are still in their infancy. In a complex engine with many interacting systems and many patterns of memory access, the task of optimizing for multiple cores is going to remain something of an art form for several years.

Its a pitty that we don’t have more published patterns on concurrent programming. While its quite frequent in the business software world, and knowledge for it abounds in that particular field, you don’t see it applied much outside of that. This as resulted in an unfortuant void of experience, outside of the business world, in dealing with multiple threads and processes, and their interactions.

Generally, the trend here is toward more and more cores on a single chip. Long-term trends point to 8, 16, 32, and more cores on one chip. Understanding the concepts of data level parallelism, Amdahl’s Law, and pipelining will become a game programmer’s core skills.

It should be noted that better languages targetting parallel processing are going to become more popular as time goes on. Most current languages do not provide even a “good” base for writing concurrent applications due to their overall design. DSLs and other HLL will help to aleviate this problem, as will the new C++0x standard, which will introduce the concept of threading into the standard, hopefully fixing some of the problems that exist in the language.

Platform support for multiple cores will also be interesting, as operating systems are not currently licensed per core but by physical processors. Thus an XP-Pro machine can use any number of cores, but a maximum of two physical processors (so, with quad core your XP-Pro machine can use 8 cores max). This type of licensing is probably going to change in the future to be parallel unit based, especially for server based operating systems.