Uh, it's really not that complicated. You can very easily compile a language with EVAL (like Lisp). Just include the compiler in the runtime, and call into the compiler to generate machine code from program fragments when necessary. This technique has been used more than once to write kernels in Lisp.
Linux shared libraries are quite different from DLLs. The shared library mechanism on *NIX systems has features that mitigate a lot of the problems of "DLL hell".
How do you think people become bitter Lispers? Years of using C++!
Levity aside, I've observed that nearly all Lispers have years (or in many cases decades) of experience in C or C++ (or more recently Java). I personally liked C++ just fine, until using it on a research project over several years. C++ ate shit in that environment. It was terrible for rapidly developing complicated algorithms, and even worse for making modifications in response to changing requirements, which are unavoidable in a research setting where you often don't know what you need until you build it. My appreciation of Lisp developed from seeing all the ways it avoided the weaknesses of C++ we encountered working on that project.
It's a bullshit excuse C++ programmers use to divert attention from the fact that C++ is a crappy language. First, C++ is not particularly powerful. Any language in the Lisp family is an order of magnitude more powerful than C++. Second, its not complex because its powerful, its complex because its poorly designed. Template "metaprogramming" makes C++ people feel elite because of its sheer obscurity, but you can do more a lot easier with a Lisp-like macro system.
I can't speak for Windows or OS X, but Linux's SMP implementation locks a process to the CPU it first runs on unless it absolutely has to move it to distribute load evenly.
You don't even necessarily need a modified gun. A good air-powered one can draw blood at range, as well as shoot right throw something like a CD at a decent distance.
Because historically Nintendo's third-parties haven't put out really deep, intense games. There's Zelda, Metroid, and RE on the GC, and painfully little else that doesn't involve a plumber with magical powers...
HDTV penetration is in the mid 20% range right now in the US, higher than in Japan or Europe.
And to say that the XBox360's games don't look that much different on 480p TVs is ridiculous. The level of geometric complexity is something completely different from what PS2 or XBox games have.
IBM is working on a compiler to split that stuff up, but that's sort of besides the point. Writing a compiler for Cell is more traditional than writing one for Itanium, but its still really hard. The SPE and PPEs are in-order, and unlike Itanium, don't have any special latency hiding mechanisms like the advanced-load-table. They also have long pipelines (~18 stages), high cache latencies (5 cycle L1 on the PPE, 6-cycle LS load on the SPE), and poor (PPE) to no (SPE) branch prediction. All the technology exists to write a compiler for such an architecture (IBM has it), but its very hard. GCC is not going to generate good code for this thing, for example.
Anyway, my point wasn't really to point out that compilers for Cell were hard, but rather that one of the reasons its getting a lot of press is that its an aggressively simple architecture. There is a large contingent of EEs (those that worship the Alpha, among other things) that really like Cell because of its ambitious design. The press regarding Cell has indeed come more from the CPU folks responding to information from IBM than from anyone in the game community (including Sony).
The article is right and you are wrong. Cell is a joint development of Sony and IBM. The ones this article is talking about, the ones that will be used in scientific computing, manufactured by IBM, has 8 SPUs, because IBM throws away the ones that have a defective SPU. Sony also makes Cell processors, for use in the PS3, and that Cell is specced to have 7 active SPUs.
That's not really true. More powerful hardware allows you to use higher-level programming techniques, pre-made game engines, etc, all of which reduce cost and reduce the time required. Also, a lot of game art is scalable, or can be made scalable. Shaders, for example, don't really care what the polygon count is, or what the output resolution is. Indeed, more power can help reduce art development time as well. Game models, for example, are usually developed at a high level, then the polygon count is pared down to optimize for the target system. If you don't have to do this process, you can save time. And powerful systems also open the way for more automated content generation tools that were perhaps not feasible before because the algorithms couldn't tune for low poly-count as well as a human designer could. For example, its pretty easy to get a terrain generator to create detailed terrain, but more complicated to get a human designer to make a terrain that looks good at low polygon counts.
Yes, game budgets are going up, but attributing it to more powerful hardware is a bit of a cop-out. The major reason game budgets are increasing is because gaming as an industry is getting bigger. The gaming industry is bigger now than Hollywood, and people are expecting more highly polished products.
Both Cell and Itanium remove complexity from the hardware, in order to fit more hardware into the available space, at the expense of more complexity in the compiler. The Itanium does this by using VLIW and eliminating OOO, and the Cell does this by eliminating OOO in the PPE and SPE, and eliminating dynamic branch prediction and hardware-managed cache in the SPE.
Hardware guys jack of to this sort of thing, because they don't have to write software for the damn things. That's one of the reasons why there has been a lot of press about Cell --- from a hardware guy's point of view (and remember, this article was in an IEEE publication), it's really an aggressive design.
That's not really the same sort of concurrency, though. game consoles have tended to have asymmetric concurrency, so the work involved less of splitting up a single algorithm to run on multiple processors and more figuring out how to run different algorithms on each processor. That's where a lot of the "one core can handle graphics, one core can handle sound, one core can handle AI" bunk comes from. Both the Xenon's cores and the Cell's SPEs are symmetric (with each other). Algorithms can be designed to utilize each of the processors for the same algorithm. Scientific programmers have a lot of experience with this (parallelizing a big matrix inversion in a finite elements code), while game programmers do not.
The problem is that its not just FF that's only on the PS2. So is Star Ocean, Xenosaga, Shadow Hearts, etc. The XBox and GC had a few RPGs here and there, but that was it. If you're an RPG fan (and there are a lot, the FF series is one of the best-selling of all time), then buying a non-Sony console just doesn't make any sense.
This might change a bit, with the RPG scene looking better on the 360 (with Blue Dragon and whatnot), but Microsoft's presence in Japan is still minimal, and Japan is still where nearly all the RPG development*
*) And a disproportionate amount of the game development in general, really. EA at #2 is an American company, and Ubisoft at #3-#4 is a French company, but most of the rest of the $500m+ third-party companies are Japanese (Capcom, Square-Enix, Konami, Sega, etc), and so are the biggest first-party companies (Nintendo, Sony).
The article doesn't even involve Sony talking up the chip. It's an IEEE article.
A lot of the Cell press has nothing to do with Sony, actually. There are a lot of EE/CompE types who get a hard-on over Cell for the same reason they do for Itanium (simple, fast hardware driven by complex compilers).
The Cell's model isn't so much complicated as it is different. The only game programmers that have any experience with multi-threading are PC developers, and SMP is the only thing they know. SMP is hardly simple, and its very hard to get right in a scalable way. In contrast, Cell's SPEs aren't DSPs, but fully general-purpose processors. As a result, if you're familiar with an MPI model of concurrency (Cell has a built-in message-passing mechanism to facilitate this), then you should feel right at home.
It depends on what you mean by "FPS". You can count Doom and Duke Nukem as FPSs, but the SNES was capable of running those too. I consider Quake to be the first true FPS, in that its the first one to give you a real first person view (you can look around). The N64 was released the day after Quake. Also, th efirst PC graphics board capable of running Quake properly (the Voodoo 1) wasn't released until four months later.
Slashdot Mirror
Uh, it's really not that complicated. You can very easily compile a language with EVAL (like Lisp). Just include the compiler in the runtime, and call into the compiler to generate machine code from program fragments when necessary. This technique has been used more than once to write kernels in Lisp.
Linux shared libraries are quite different from DLLs. The shared library mechanism on *NIX systems has features that mitigate a lot of the problems of "DLL hell".
How do you think people become bitter Lispers? Years of using C++!
Levity aside, I've observed that nearly all Lispers have years (or in many cases decades) of experience in C or C++ (or more recently Java). I personally liked C++ just fine, until using it on a research project over several years. C++ ate shit in that environment. It was terrible for rapidly developing complicated algorithms, and even worse for making modifications in response to changing requirements, which are unavoidable in a research setting where you often don't know what you need until you build it. My appreciation of Lisp developed from seeing all the ways it avoided the weaknesses of C++ we encountered working on that project.
It's a bullshit excuse C++ programmers use to divert attention from the fact that C++ is a crappy language. First, C++ is not particularly powerful. Any language in the Lisp family is an order of magnitude more powerful than C++. Second, its not complex because its powerful, its complex because its poorly designed. Template "metaprogramming" makes C++ people feel elite because of its sheer obscurity, but you can do more a lot easier with a Lisp-like macro system.
I can't speak for Windows or OS X, but Linux's SMP implementation locks a process to the CPU it first runs on unless it absolutely has to move it to distribute load evenly.
Clarification: it was contracted by BMG before Sony bought BMG.
Also, that's really the whole point of a corporation, the concept of "limited liability".
Because it was at best negligent distribution of spyware (the software was contracted by their BMG subsidiary prior to their buying it).
And the problem with wind power is that its logistically unworkable on a large scale.
God, I wish the environmentalist would take the same position with regards to nuclear power!
You don't even necessarily need a modified gun. A good air-powered one can draw blood at range, as well as shoot right throw something like a CD at a decent distance.
Because historically Nintendo's third-parties haven't put out really deep, intense games. There's Zelda, Metroid, and RE on the GC, and painfully little else that doesn't involve a plumber with magical powers...
HDTV penetration is in the mid 20% range right now in the US, higher than in Japan or Europe.
And to say that the XBox360's games don't look that much different on 480p TVs is ridiculous. The level of geometric complexity is something completely different from what PS2 or XBox games have.
HDTV penetration in the US is higher than in Japan (or in Europe), and is around the 25%+ mark now.
goto isn't necessarily hard to optimize. LLVM lowers all control flow to goto anyway, for example.
Goto is often the only sane way to do error handing in a language as braindead as C.
That's exactly what I said. The Sony Cells are specced to have 7 active cores, so they can still use ones whose 8th core is defective.
IBM is working on a compiler to split that stuff up, but that's sort of besides the point. Writing a compiler for Cell is more traditional than writing one for Itanium, but its still really hard. The SPE and PPEs are in-order, and unlike Itanium, don't have any special latency hiding mechanisms like the advanced-load-table. They also have long pipelines (~18 stages), high cache latencies (5 cycle L1 on the PPE, 6-cycle LS load on the SPE), and poor (PPE) to no (SPE) branch prediction. All the technology exists to write a compiler for such an architecture (IBM has it), but its very hard. GCC is not going to generate good code for this thing, for example.
Anyway, my point wasn't really to point out that compilers for Cell were hard, but rather that one of the reasons its getting a lot of press is that its an aggressively simple architecture. There is a large contingent of EEs (those that worship the Alpha, among other things) that really like Cell because of its ambitious design. The press regarding Cell has indeed come more from the CPU folks responding to information from IBM than from anyone in the game community (including Sony).
The article is right and you are wrong. Cell is a joint development of Sony and IBM. The ones this article is talking about, the ones that will be used in scientific computing, manufactured by IBM, has 8 SPUs, because IBM throws away the ones that have a defective SPU. Sony also makes Cell processors, for use in the PS3, and that Cell is specced to have 7 active SPUs.
That's not really true. More powerful hardware allows you to use higher-level programming techniques, pre-made game engines, etc, all of which reduce cost and reduce the time required. Also, a lot of game art is scalable, or can be made scalable. Shaders, for example, don't really care what the polygon count is, or what the output resolution is. Indeed, more power can help reduce art development time as well. Game models, for example, are usually developed at a high level, then the polygon count is pared down to optimize for the target system. If you don't have to do this process, you can save time. And powerful systems also open the way for more automated content generation tools that were perhaps not feasible before because the algorithms couldn't tune for low poly-count as well as a human designer could. For example, its pretty easy to get a terrain generator to create detailed terrain, but more complicated to get a human designer to make a terrain that looks good at low polygon counts.
Yes, game budgets are going up, but attributing it to more powerful hardware is a bit of a cop-out. The major reason game budgets are increasing is because gaming as an industry is getting bigger. The gaming industry is bigger now than Hollywood, and people are expecting more highly polished products.
Way to miss the point COMPLETELY.
Both Cell and Itanium remove complexity from the hardware, in order to fit more hardware into the available space, at the expense of more complexity in the compiler. The Itanium does this by using VLIW and eliminating OOO, and the Cell does this by eliminating OOO in the PPE and SPE, and eliminating dynamic branch prediction and hardware-managed cache in the SPE.
Hardware guys jack of to this sort of thing, because they don't have to write software for the damn things. That's one of the reasons why there has been a lot of press about Cell --- from a hardware guy's point of view (and remember, this article was in an IEEE publication), it's really an aggressive design.
That's not really the same sort of concurrency, though. game consoles have tended to have asymmetric concurrency, so the work involved less of splitting up a single algorithm to run on multiple processors and more figuring out how to run different algorithms on each processor. That's where a lot of the "one core can handle graphics, one core can handle sound, one core can handle AI" bunk comes from. Both the Xenon's cores and the Cell's SPEs are symmetric (with each other). Algorithms can be designed to utilize each of the processors for the same algorithm. Scientific programmers have a lot of experience with this (parallelizing a big matrix inversion in a finite elements code), while game programmers do not.
The problem is that its not just FF that's only on the PS2. So is Star Ocean, Xenosaga, Shadow Hearts, etc. The XBox and GC had a few RPGs here and there, but that was it. If you're an RPG fan (and there are a lot, the FF series is one of the best-selling of all time), then buying a non-Sony console just doesn't make any sense.
This might change a bit, with the RPG scene looking better on the 360 (with Blue Dragon and whatnot), but Microsoft's presence in Japan is still minimal, and Japan is still where nearly all the RPG development*
*) And a disproportionate amount of the game development in general, really. EA at #2 is an American company, and Ubisoft at #3-#4 is a French company, but most of the rest of the $500m+ third-party companies are Japanese (Capcom, Square-Enix, Konami, Sega, etc), and so are the biggest first-party companies (Nintendo, Sony).
The article doesn't even involve Sony talking up the chip. It's an IEEE article.
A lot of the Cell press has nothing to do with Sony, actually. There are a lot of EE/CompE types who get a hard-on over Cell for the same reason they do for Itanium (simple, fast hardware driven by complex compilers).
The Cell's model isn't so much complicated as it is different. The only game programmers that have any experience with multi-threading are PC developers, and SMP is the only thing they know. SMP is hardly simple, and its very hard to get right in a scalable way. In contrast, Cell's SPEs aren't DSPs, but fully general-purpose processors. As a result, if you're familiar with an MPI model of concurrency (Cell has a built-in message-passing mechanism to facilitate this), then you should feel right at home.
It depends on what you mean by "FPS". You can count Doom and Duke Nukem as FPSs, but the SNES was capable of running those too. I consider Quake to be the first true FPS, in that its the first one to give you a real first person view (you can look around). The N64 was released the day after Quake. Also, th efirst PC graphics board capable of running Quake properly (the Voodoo 1) wasn't released until four months later.