Slashdot Mirror
John Carmack Discusses 360's Edge, Considers DS
Via a Gamasutra post, John Carmack's comments on upcoming id choices. Game|Life has a few quick comments on Carmack's hope to bring Orcs and Elves to the DS. This would be id's first game on a Nintendo platform in some time. Likewise, he makes it clear that he considers the 360 the dev platform of choice due to the ease of development on the console. From the article: "the honest truth is that Microsoft dev tools are so much better than Sony's. We expect to keep in mind the issues of bringing this up on the PlayStation 3. But we're not going to do much until we're at the point where we need to bring it up to spec on the PlayStation 3. We'll probably do that two or three times during the major development schedule. It's not something we're going to try and keep in-step with us. None of my opinions have really changed on that. I think the decision to use an asymmetric CPU by Sony was a wrong one."
"their tools are more based on Asian design and logic"?
What a bizarre concept. When I worked for a software company in Japan, the only way that culture intruded into software development (aside from an organizational structure that makes Dilbert's seem positively effective) was the fact that programmers who could used English manuals. Japanese manuals and other reference/instructional materials were so vague and information-poor that the language barrier was easier for my co-workers to overcome than reading materials in their native tongue!
I will grant you that Asians (East Asians, at least) seem much more comfortable with interfaces that we find incredibly cluttered. But that's not programming as such.
You would have to read my post about software engineering vs. development to understand a bit more about where I am coming from. I don't like that Sony has changed architecture in every console release, this has been a detriment to what they can achieve, but now they have IBM on board so I doubt the Cell Architecture is going away anytime soon. For now it is harder to program and takes a little more time, but that will change, as it does with every new architecture. As more development tools are available the programming will become easier, as more libraries and engines become available it will become even easier. Once you start thinking parallel you actually see that it is easier than not as it allows better division of code and work. If the next generation of servers, consoles, and consumer electronics are powered by the Cell Processor, as IBM, Sony and Toshiba claim, then you will see the necessary tools and mind shifts happen at a very rapid pace.
As a Software Engineer I grow more an more disgusted with the x86, and to a lesser extent Power, architecture every day. Ah if only I could go back to the CBM days.
Um... Computer hardware is made up of a number of components using digital circuits, which in turn use logic gates, which are a circuit representation of Boolean Logic.
Besides, what do you think if() and while() do in programs? How about == and !=? <, <=, >, and >= are just a series of boolean comparisons.
That isn't to say you can write an application using just boolean logic, as you'd need math in there at some point...
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Didn't quake 3 run in linux?
You mad
Not only is there the issue of 1 main core with 8 additional cores, the 8 additional cores don't have random access to main memory and are really only efficient at doing stream processing - they are tuned for vector operations. I'd agree that the GP(and GGGP) missed the point. The issue is not single core vs. multi-core - it's standard multi-core shared memory architecture vs. whack-ass-we-designed-it-ourselves-DSP-style-multi -core. Developers get the idea of multithreaded programming - it's hard, but they understand it. It gets much harder when you have to manually handle memory transfers for each of the threads to ensure they have the data they need to process.
Course. Quake 4, Doom3 and Unreal Tournament 2004 too.
## NB: Comment here
All the posters who seem like they know what they're talking about are simply ignored.
Actually, the 360 is multi-core, not multi-processor (it has a single Xenon CPU with 3 symmetrical PPC-based cores), and multi-core is more of a cost optimization and less of a performance one (AMD's communication overhead reduction between cores, as well as cache-sharing technologies, is an optimization only viable through the use of multi-core packages, but as Intel's old dual-core P4 showed, you can create a dual-core CPU by slapping two regular processors in a single package / on a single die without any such optimization)
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
I am well aware of the software cache, and auto-SIMDization. I was involved in getting the tutorials on those topics prepped last fall, and I've done a bunch of other writing on this. I am a big fan of Cell, and I spend more time than is probably healthy immersed in reading or writing about it.
The software cache imposes a fair number of cycles of latency per access even when the datum in question is in the cache; it's even slower when the datum isn't in the cache. Is it useable? Certainly. However, it's going to give you a serious performance hit, especially when used heavily. You can't just use it and get full performance from the SPE without worrying about local store; you have to use it sparingly only for access to large chunks of data, while keeping the bulk of the data you're working on in local store all the time. It does not solve the problem; it mitigates it.
The auto-SIMDization stuff does not make scalar code efficient. What that does is, in some cases, automatically convert scalar operations on arrays into vector operations on the same arrays. It doesn't solve the more general problem of operations that aren't being performed on whole arrays; those stay slow. what's impressive is that they handle the alignment problems involved in vectorizing, e.g., a[i] = b[i + 1] * c[i + 3];, not that they have magically cured the problem.
So we're back to where we started. The cell development support and compiler can give you comparative ease of use, but you lose a lot of the performance potential of the processor. All those theoretical numbers you see are based on the assumption that you are doing 90% of your calculations with no latency; not waiting for DMA, not accessing a cache, and so on.
So, really, you do have to do a lot of extra work to get the theoretical performance, or even very close to it. The software cache and other techniques mitigate this, so you can get enough performance from the SPEs to benefit from them somewhat without having to do anything exceptionally elaborate, but they don't give you the theoretical performance. If you want that performance, you have to do a lot of fiddly little management of, for instance, the tiny local store available on the SPEs. If you want to have that handled automatically, you take a very noticeable performance hit.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
From what I've heard, Nintendo has two offices in Redmond. One is the corporate office, which is similar to what you're talking about. Marketing, sales, localization, etc. The other is Nintendo Software Technology. That office actually makes games. They opened in time for GameCube development. They did WaveRace: Blue Storm, 1080 Snowboarding: Avalanche, and Metroid Prime: Hunters. Probably more, but that's all I'm certain of.