by Carol Schiraldi
I’m not a gamer myself, but the recent launch of the PS3 and Wii consoles (podcast from Gamingbits available here) makes this a good time to discuss game programming and the idea of performance in the enterprise.
Austin is a big center for video game development – NCSoft, Midway Studios-Austin and Retro Studios are all located here – and I know many game programmers. I think that game programmers are some of the best programmers out there, and a lot of performance enhancements are coming from gaming.
If you code for gaming, there’s a different mindset. Emphasis on performance is included (and essential) by design.
Gaming programmers are performance-oriented to the extreme, because if you release a game and it’s slow, no one is going to use it no matter how cool it is or how many features it has. Other programmers often code first for functionality, and at the end of the cycle, start to worry about performance issues. Game programmers need optimized performance from the get-go. This means game programmers are willing to forgo certain things. For example, the enterprise side of the software world was very quick to move to Java when it first came out, but the game programmers didn’t.
Part of that was because Java didn’t have all the necessary libraries. They advertised “write once, run anywhere,” but it really wasn’t true in early versions of Java. You needed the AWT for your platform. It was more like “write once, run almost anywhere with the right library.” The game programmers caught onto that very quickly, and refused to jump on the Java platform.
On the other hand, enterprise developers adapted Java quickly for different reasons. Java applets can be excruciatingly slow, but enterprise apps don’t always use applets. They usually end up using Swing, J2EE, or JSP. If you look at JSP, it’s on the server side, and you can performance tune the server for the application. The page gets processed on the server side, and only the output is loaded on the client side.
Java on the server also cuts down on testing time because you don’t have to test your server-side app for a number of different client configurations. You can just test on the server you plan to use.
Java’s really good for middleware – messaging apps or services (aka enterprise application integration, or EAI), that sort of thing. And though many people complained about the performance of CORBA apps, if you compare it with other solutions, performance remains competitive to COM/DCOM and .Net. It’s scalable, it’s stable, it’s reliable, and it’s relatively fast on the server – all things you look for in enterprise apps.
When they introduced the Java Gaming Platform, it never took off with the game developers until the past year or two because game programmers, who care more about performance, preferred to use C++ because it’s faster. (For more on the Java vs. C++ debate, see this lively discussion on The Game Programming Wiki.)
Of course, Java has recently gone GPL, and this might have an impact upon overall application performance, as open-source programmers will now be free to optimize previously “closed” classes, which, in turn, might help improve end to end network performance and run-time performance.
Java, as a programming language, started out with a lot of libraries and extensions. The beginnings of Java had more breadth than depth, and some of its early API’s were problematic. By going Open Source now, the language can sort of “fill in the dots” to provide what the programming community feels is missing.
Carol Schiraldi is a Senior Software Engineer at NetQoS.
No comments yet.