Multithreading a workload is hard, and so is optimizing your code for a statically scheduled machine with weak hardware branch prediction. Branch hints, code and data prefetching, and other compile-time techniques that require coders to shoulder the burden of optimally using a complex array of hardware execution resources are no fun for developers. Even more importantly, it's not yet clear exactly how or even if all of this stuff can be profitably applied to some important classes of software. So any developer in their right mind would vastly prefer a traditional, dynamic execution CPU with a beefy branch predictor and a large cache to what IBM produced. That's because the traditional CPU does many of the hard parts of the coder's work for them: the dynamic execution core uses its instruction window to reschedule code optimally at run-time, the branch prediction hardware means that the developer doesn't have to rely on branch hints and other software tricks to keep the pipeline full, and the large cache means that the developer doesn't have to hassle with code and data prefetching and the like. In short, a CPU like the Athlon64 is designed to run anything but the most pathologically worst-case code really, really fast.
The developer frustration expressed in the article is in large part a result of the fact that the free ride is over for the software industry. In the good old days before we hit the power wall, the vast majority of performance improvements came from improvements on the hardware side. Furthermore, the two hardware improvements that coders could count on with each generation of CPUs were more clockspeed and more cache. Clockspeed and cache sizes increases have literally carried the industry along for the past two decades. Sure, software optimization matters at the level of the individual platform-—optimized code clearly runs faster than unoptimized code on any given processor. But looking at the big picture, clockspeed and cache size increases have been the real macro-level software performance drivers. The software industry could always count on those two factors to furnish steady improvements in application performance.
But like I said above, that free ride is over, and now it's time to face the multithreaded, multicore music. In the new world, a world of which both the Xenon and the Cell are a part, programmers have a whole lot more work to do, in terms of both splitting their applications up into threads and of optimizing those individual threads. The fact that they haven't yet been able to figure out how to make applications that they learned how to write on the old hardware work on the new hardware is completely unsurprising. The old hardware had a theoretical performance peak and lots of hardware aimed at helping applications reach that peak; the new hardware has a higher theoretical performance peak, and little to no hardware aimed at helping applications reach that peak. So developers have a longer distance to go, and they have less help in getting there. It certainly makes for a vexing combination, but it's way too early to say that it's the end of the world.
Things not mentioned:
-- Most developers have an existing codebase based upon the old CPU architectures. Any programmer in his right mind will NOT like the idea of rewriting all the core aspects of his engine just to get decent performance. Of course, this will have to occur anyway over the long term but the real problem is that imminent arrival of these consoles forces programmers to do this task quickly in order to meet deadlines. It's especially horrible because the final XDK STILL hasn't been released.
-- The real issue that is driving this outcry is simply common business sense. Code costs, and there is a lot of XBox and PS2 (soon to be legacy) libraries that development houses have invested a lot of money in over the years.
-- Multi-platform support just got increasingly harder. Though PCs/Macs are going multi-core each of these cores share the exact same functionality of a normal single core CPU. On the other hand the consoles have CPU architectures where each processor is designed for certain tasks. In short programmers will need to redesign core aspects of their engine for EACH platform in order to get optimal performance.
-- For developers wanting a quick turnaround many programmers might just toss physics and AI along with graphics API calls onto the extra processors and call it a day. This might not be optimal but at least you'll get a quick benefit from the multi-processor design and be able to meet deadlines.
-- Many developers in the mainstream industry have come to the point where they'd rather focus on the gameplay and content creation with the technology as a side distraction. Take the business model of Wideload Games for example.
Alexander Seropian created the company Bungie (and left after Halo to start Wideload Games) and this is what he had to say on the subject in a recent interview:
What are you doing at Wideload to resolve modern development problems?
The way we're set up, we have a small team, 10 going on 11, and we're the core design team. We come up with the game ideas, intellectual property, and prototypes. We take it from inception to viability. When we do put it into production, when it's ready, we staff up with independent employees. That way, I don't have to carry a 50 or 60 person payroll throughout the whole development cycle.
How did you come up with this model?
It's not very different from the way films are made. In reality, if you have 60 people on a project, not all 60 people can be the visionary. We can keep this group here that's internal and keep that creative culture you have when you only have dozen guys in a room. It's hard to get that atmosphere in a large company (or to agree on anything).
It sounds like you want to do the fun stuff, then hire grunts to do the hard stuff.
Everything you do is all to produce a tool to make a game. Software's a big part of it, and programming is a fun and cool endeavor on its own; but all that code and building of engines are put into producing a robust set of tools to allow you to tell a story, to create an escape. From my perspective, at Bungie we did this all the time. We spent years making the tools and the software to let everyone create stuff. It's not that I see tech becoming a commodity, but I would rathe rspend two years coming up with a cool new set of characters, rules, and worlds. I'd rather do that then spend four years making a tool. I think we're getting to the point where, with consoles, you don't need to reinvent the wheel every time. You certainly want to change it, move it forward, but that's another part of the goal of this company: to not reinvent the tech every time.
[This message has been edited by Gump (edited June 30, 2005).]