One of strengths of the XBox is that it is really just a pc. Porting to and from it to the PC is really simple.
Nonense. Porting an Xbox game to the PC isn't that hard, yes, but the other way is rough. In all honesty, just because there's a small subset of Direct3D on the Xbox doesn't make it a PC at all.
In my opinion that comment is a HUGE copout! I absolutely believe a good game can be written by someone with average programming skills and above-average creativity.
The majority of the cost of a game is content--sound, art, animation--not programming.
Phone systems, for example, are designed to handle a particular load. That load is "a small percentage of all customers simultaneously." So if you have an area with 100,000 people, maybe you can handle 10,000 simultaneous phone calls in an exchange. It's generally not worth the 10x increase in cost just to be able to handle worst-case scenarios. And really, it's not like emergency services will be able to deal with even 10,000 calls at once.
You don't have to save anything you don't use, and you (the compiler) should only use extra registers if it is advantageous to do so (taking into account the cost to save/restore them). Having more registers available simply gives you more options.
That's the optimist's view. In reality it's less clear than that. When you see 20+ instructions to handle entry and exit code, then that strikes me as RISC gone wrong. And this is with a good compiler, not just some student project.
As an aside, when you pass parameters in registers you often have to turn around immediately and copy them to different registers or write them out to memory. It's not hard to come up with cases where it's faster to pass parameters on the stack.
Your example is not a good one. I disassemble x86 code and see instructions pushing parameters onto the stack. I disassemble PPC code and see instructions moving parameters into registers. How good is x86 with functions that have a large amount of local storage and a large number of parameters?
You're talking about the caller. I'm talking about what happens in the function that you're calling. On the x86, the return address is pushed on the stack as part of the "call" instruction (and popped as part of "ret'). On the PPC, both of these translate into multiple instructions (for non-leaf functions). On the x86 you typically only save and restore a handful of registers: ebx, esi, edi. On the PPC you potentially have to save and restore a dozen or more registers. I routinely see functions with 48 or more bytes of set-up and tear-down, but it can be much larger.
PPC is one of the best platforms ever for both sound, gfx and of course heat production.
Is this based on more than just personal feelings about the architecture? Honestly, I like the PPC. It's a great implementation of the classic RISC principles: lots of registers, simple and fast instructions, no hardware stack, etc. But, really, this is just geeky fawning over a pretty design. The x86 is certainly ugly in some ways, mostly in terms of the huge legacy instruction set, but it's not so bad overall. Having hardware stack support is very nice. The limited number of registers makes function call overhead very low. If you disassemble code for typical PPC applications, you may see dozens of instructions for entering and leaving a function. And with each of those instructions being 4 bytes, that's a big deal in terms of instruction cache usage. So it's not entirely clear that in the modern world a classic RISC architecture is better.
Desktops will be around for a long, long time. Further, I feel that the notebook trend will peak and probably head back in the other direction in a few years. The reason is, it's fundamentally more expensive to build a portable computer than a desktop.
But notebooks are tremendously more useful and appealing. End of story:)
A really new architecture should abandon the algorithmic model and adopt a non-algorithmic, signal-based synchronous software model. It would revolutionize computing and solve the nastiest problem in the computer industry: software unreliability.
Of course something that radical would be useless to the desktop/notebook market as a whole. You'd have to start a whole new type of PC to take advantage of it, one that's fundamentally incompatible with everything else out there. Don't get me wrong, I'd love to see that, but I'm not holding my breath.
There are lot of other options for radical shifts in processor design. At the moment, both Intel and AMD are spinning their wheels, designing chips like crazy but the improvements are incremental and small. No one has broken through the wall that has kept CPU design in a holding pattern for the last three or more years. 64-bit has been a lot of noise, and it hasn't come into its own yet (even among high-end users, you'll rarely find anyone begging for more than 2GB of memory). The other big issue that that notebooks and gadgets are the future, not desktops, so low power is a huge deal.
100% software reliability! Guaranteed!
What is this based on? How are you going to get 100% software reliability by using different processors?
If a commerce or community site saves a cookie, then that's fine. There's a purpose for cookies on amazon and slashdot. But it seems that every little blog out there sets cookes, as do all little tech journals and so on. There's no reason for this.
I would make one or more physics threads, one or more AI threads, a sound thread, a rendering thread, a resource managment thread, and perhaps a culling thread which assisted the VPU with geometry occlusion if the CPU is ahead of the VPU. I'd also put in a semaphore queue mechanism so some of these could get a frame or two ahead without syncing.
All of these threads, however, may need to interact with each other. When objects collide, you get a callback and that callback may trigger rendering, AI, sound, etc. AI needs to use physics data for line-of-sight checks and so on. My point is that dividing these things up cleanly is nowhere near an obvious task. And think of all the horrible timing-specific bugs you could end up with. You can't do Test-Driven Development with thread interactions.
Re:Something borrowed, nothing new
on
IE7 Bugs and Reviews
·
· Score: 3, Insightful
Tabbed browsing has been added, dropdown search, add-on manager. Now where have I seen those all before?
In the big picture, those are just tweaks. Microsoft engineers spent tens of thousands of hours working on IE, so adding tabbed browsing was likely relatively easy.
Firefox advocates/users who have been acting as if things like tabbed browsing, ad blocking, and so on, are huge, difficult, quantum leaps...they've been deluding themselves. Firefox has always come across as IE + some extra niceties. That's why I use it.
The Apple II wasn't 'OS-less' by any stretch of the imagination. It used either Apple DOS or Apple ProDOS as its OS, depending upon which machine and applications you were talking about. I don't know much about the architecture of the C64, but I'll bet it was hardly 'OS-less'.
You can consider the Apple II to be OS-less. When your code was running, absolutely nothing interfered with it. No other processes were running. You could write to any memory address you wanted. You put graphics up on the screen by writing directly to the memory associated with it. What the Apple II did have was a set of utility routines, either in ROM or loaded from the DOS boot disk. But you could live just fine without those routines if you chose to do so.
The Atari 800, to give another example, had a little mini-OS that was essentially there to provide services for BASIC and other language environments: simple screen I/O, simple copying of values from RAM to hardware registers during the vertical blank (to allow POKE-ing in BASIC without mid-frame flicker). Things like that. But you could just as easily take over the whole machine and do whatever you wanted, and that was common, because the OS services did nothing useful for you most of the time.
Remember, notebooks are about more than speed
on
New iBook and Apple mini
·
· Score: 4, Informative
The key is to get something light, compact, cool running, good battery life, and yet still have good enough performance to be acceptable for most things. The goal is not by any means to have the fastest computer out there. Remember, if you really need the ultimate performance, you can always by a desktop. Or you could have just bought one of the current model PowerBooks instead of an iBook (though it's still not in the same ballpark as a high-end desktop). If you think about it, a 1.4GHz G4 with 3D acceleration standard, well, that's a pretty good machine for most things. Thinking back a few years, I developed commercial 3D games with desktops that were much lower powered than that. (For a real laugh, go back and look at what John Carmack used to develop Quake, remembering that Quake 1 was initially software rendering only.)
Realistically, the iBook is not a hardcore gaming machine. You're not going to find many PCs in the same price range that can play DOOM 3 with all the bells and whistles turned on either. And I'd argue that this is okay. High-end 3D games like this are a niche.
In terms of CoreImage, I think many people don't understand what it is. It is not QuartzExtreme. All 2D graphics are going through OpenGL on the iBook, so things will be snappy and take advantage of the GPU. CoreImage is about what are essentially Photoshop filters and special effects, not fundamental rendering. And being a fairly new OS X technology, it's not clear how much CoreImage is actually being used right now, or if it will come into its own in the future.
In fact, no one should need a computer over 1GHz! Therefore, we should not make power supplies or parts that are meant to supply something over a simple processor, video/sound card, and hard drive.
That's the classic overreaction. But stop and think about it: a good many people are beefing up their machines to ridiculous levels--450W power supply, super high-end video card, 3.6GHz CPU, fancy add-on sound card, 2GB of RAM--simply so they get lightning frame rates in some upper crust 3D games. 95% of the time all of that hardware is just sitting there. Now it's true that a GPU uses less power when it's sitting idle, but there's still a significant increase in power draw by putting in all these components. This especially applies to CPUs, where the cutting edge models (like a 3.6GHz P4) use substantially more power than run-of-the-mill "really fast" models, like the 3.2GHz P4. Is the increase in power consumption worth it for the 12.5% increase in clock speed? Doubtful.
This is hard to get across unless you followed personal computer developments in those days, but there was a definite excitement surrounding the release of entirely new home computers in those days. The Atari 800, the Amiga, the Atari ST, the Commodore 64, the Macintosh. Think about it: the Amiga had a brand new OS, brand new graphics and sound hardware...it was stunningly different. That's nowhere near the same thing as an incremental video card upgrade that still works through DirectX or a Dell that just has some different numbers in terms of bus speed, CPU speed, memory, etc.
The mid-80s were exciting times. In 1984 the Mac was released. The Atari ST and Amiga in 1985. The Apple IIgs in 1986. Then the color Macintosh in 1987.
The last time I felt this in regard to consumer-level computers was when the Be-Box was first announced. Since then it's just when new game consoles come along.
There's nothing about BF2 that wouldn't work just as well on a console. It doesn't push any kind of graphical limits. It would work great with a typical console controller. It's a great game, yes, but that has nothing to do with it being a PC title.
I don't understand why some people are so anti-console. Look at it this way: a console typically costs less than a flashy PC graphics card, so why not just get one and have fun with it? That doesn't mean you can't also play PC games. If you've been completely blowing off consoles, then you've been missing out on some wonderful gaming experiences.
Somebody who loves computer science, like myself. I will be a freshman in the fall studying computer science. Computer science is a very interesting topic to study and to research, which is what I intend to do once I'm done with college.
Do you mean you want to do academic research after you're done with college--or some kind of research anyway? Or are you wanting to get a job as a programmer?
Bad: Batteries. You have to buy them (and throw them away) or recharge them, and monitor when they need replacing/recharging. A wire is a much simpler solution.
As for technology trends, Jobs just stumbles. His single biggest mistake is not porting the MacOS to x86 back in 1984 so that IBM PC users could run the operating system.
That's a ballsy statement. Most obviously, the Mac was intended to be an appliance with fixed and integrated hardware, right down to the floppy being ejected under software control. And then of course the PC was a fairly lame duck in 1984: segmented memory, mice were nonexistent, poor graphics support (and certainly without the square aspect ratio of the Mac display), only the built-in speaker for sound, etc.
The transition from 68K to PPC was chaotic for both users and developers, and I see no reason it isn't going to be the same this time around.
Quite a few apps never made the transition back then, but you didn't know which ones would and which ones wouldn't until you had the benefit of hindsight. The ones that didn't ran via emulation layer, but you paid a huge performance price for those. You bought high-end and pricey hardware, only to have your apps run slower than hardware from years earler.
Transitions like this are also huge for smaller developers. We're just getting to the point where many third party apps and development tools work well under OS X. Now all of a sudden they've got to budget what could be a massive port. Sure, Rosetta, blah, blah, blah, but think about what the makers of native code Lisps for the Mac are going through right now, for example. Likely, quite a few projects will die out. What about Mike Hoare's excellent Mops environment, which generates PowerPC code natively? This is going to be rough.
Personally, I've been on the verge of buying either an iBook or PowerBook. Now I don't see any reason to buy what's going to be legacy technology. Apple has completely lost me here.
Okay, laugh at me in a few hours if Apple does switch to the x86, but I don't think it's doing to happen. The x86 is too backward, too much of an old-school PC processor, for the crowd that Apple has been courting of late. And they key point is that it isn't worth running *all* software through emulation for *years* just to make a crazy switch like this. The emulation issue will make Macs seem much slower than equivalent PCs, regardless of price.
It's going to be one of the following:
1. PowerPC chips manufactured by Intel, in an effort to bring down the price and increase the clock speed. This is the most likely option.
2. Itanium. Maybe. Possibly. Intel desperately wants Itanium to succeed ant it *does* give ultra high performance if you blow off the x86 emulation nonsense.
3. ARM. Some kind of low-power alternative for notebooks. Doubt it, though.
It could be Itanium. Or ARM. Honestly, I don't see Apple going x86, because of the whole "think different" attitude.
From a tech point of view, it would be a shame for Apple to switch from the beautiful PPC chips to the ugly duckling x86. Apple has been been making some top notch technical choices, resulting in lots of geek cred, with the PPC line and OS X, so I just can't see the x86 making sense here.
(Itanium is an interesting possibility, in that Intel knows that line of chips is floundering, so Apple could walk in and save the day.)
PC gaming is never going to go away. Simply put, there is an installed base of several hundred million users.
And yet console games outsell PC games by a huge margin. A console blockbuster like GTA sells 5+ million copies. A PC blockbuster like Half-Life 2 is lucky to hit a million (and there are hardly any games in the HL2 class on the PC).
Open the systems to anyone and everyone to develop new programs and make it easy to share those programs with other users. With the power these boxes have there are a lot of possibilities but as always the mainstream is going to play it safe and try to deliver only what they have experience with.
Of course, console games take 2+ years, $8+ million dollars, and 50+ people to develop. The majority of that goes into art creation time: models, textures, animation, levels, etc. This is outside the range of individuals, even a dedicated group on the internet.
Slashdot Mirror
One of strengths of the XBox is that it is really just a pc. Porting to and from it to the PC is really simple.
Nonense. Porting an Xbox game to the PC isn't that hard, yes, but the other way is rough. In all honesty, just because there's a small subset of Direct3D on the Xbox doesn't make it a PC at all.
In my opinion that comment is a HUGE copout! I absolutely believe a good game can be written by someone with average programming skills and above-average creativity.
The majority of the cost of a game is content--sound, art, animation--not programming.
Phone systems, for example, are designed to handle a particular load. That load is "a small percentage of all customers simultaneously." So if you have an area with 100,000 people, maybe you can handle 10,000 simultaneous phone calls in an exchange. It's generally not worth the 10x increase in cost just to be able to handle worst-case scenarios. And really, it's not like emergency services will be able to deal with even 10,000 calls at once.
You don't have to save anything you don't use, and you (the compiler) should only use extra registers if it is advantageous to do so (taking into account the cost to save/restore them). Having more registers available simply gives you more options.
That's the optimist's view. In reality it's less clear than that. When you see 20+ instructions to handle entry and exit code, then that strikes me as RISC gone wrong. And this is with a good compiler, not just some student project.
As an aside, when you pass parameters in registers you often have to turn around immediately and copy them to different registers or write them out to memory. It's not hard to come up with cases where it's faster to pass parameters on the stack.
See SufficientlySmartCompiler.
Your example is not a good one. I disassemble x86 code and see instructions pushing parameters onto the stack. I disassemble PPC code and see instructions moving parameters into registers. How good is x86 with functions that have a large amount of local storage and a large number of parameters?
You're talking about the caller. I'm talking about what happens in the function that you're calling. On the x86, the return address is pushed on the stack as part of the "call" instruction (and popped as part of "ret'). On the PPC, both of these translate into multiple instructions (for non-leaf functions). On the x86 you typically only save and restore a handful of registers: ebx, esi, edi. On the PPC you potentially have to save and restore a dozen or more registers. I routinely see functions with 48 or more bytes of set-up and tear-down, but it can be much larger.
PPC is one of the best platforms ever for both sound, gfx and of course heat production.
Is this based on more than just personal feelings about the architecture? Honestly, I like the PPC. It's a great implementation of the classic RISC principles: lots of registers, simple and fast instructions, no hardware stack, etc. But, really, this is just geeky fawning over a pretty design. The x86 is certainly ugly in some ways, mostly in terms of the huge legacy instruction set, but it's not so bad overall. Having hardware stack support is very nice. The limited number of registers makes function call overhead very low. If you disassemble code for typical PPC applications, you may see dozens of instructions for entering and leaving a function. And with each of those instructions being 4 bytes, that's a big deal in terms of instruction cache usage. So it's not entirely clear that in the modern world a classic RISC architecture is better.
Desktops will be around for a long, long time. Further, I feel that the notebook trend will peak and probably head back in the other direction in a few years. The reason is, it's fundamentally more expensive to build a portable computer than a desktop.
:)
But notebooks are tremendously more useful and appealing. End of story
A really new architecture should abandon the algorithmic model and adopt a non-algorithmic, signal-based synchronous software model. It would revolutionize computing and solve the nastiest problem in the computer industry: software unreliability.
Of course something that radical would be useless to the desktop/notebook market as a whole. You'd have to start a whole new type of PC to take advantage of it, one that's fundamentally incompatible with everything else out there. Don't get me wrong, I'd love to see that, but I'm not holding my breath.
There are lot of other options for radical shifts in processor design. At the moment, both Intel and AMD are spinning their wheels, designing chips like crazy but the improvements are incremental and small. No one has broken through the wall that has kept CPU design in a holding pattern for the last three or more years. 64-bit has been a lot of noise, and it hasn't come into its own yet (even among high-end users, you'll rarely find anyone begging for more than 2GB of memory). The other big issue that that notebooks and gadgets are the future, not desktops, so low power is a huge deal.
100% software reliability! Guaranteed!
What is this based on? How are you going to get 100% software reliability by using different processors?
If a commerce or community site saves a cookie, then that's fine. There's a purpose for cookies on amazon and slashdot. But it seems that every little blog out there sets cookes, as do all little tech journals and so on. There's no reason for this.
I would make one or more physics threads, one or more AI threads, a sound thread, a rendering thread, a resource managment thread, and perhaps a culling thread which assisted the VPU with geometry occlusion if the CPU is ahead of the VPU. I'd also put in a semaphore queue mechanism so some of these could get a frame or two ahead without syncing.
All of these threads, however, may need to interact with each other. When objects collide, you get a callback and that callback may trigger rendering, AI, sound, etc. AI needs to use physics data for line-of-sight checks and so on. My point is that dividing these things up cleanly is nowhere near an obvious task. And think of all the horrible timing-specific bugs you could end up with. You can't do Test-Driven Development with thread interactions.
Tabbed browsing has been added, dropdown search, add-on manager. Now where have I seen those all before?
In the big picture, those are just tweaks. Microsoft engineers spent tens of thousands of hours working on IE, so adding tabbed browsing was likely relatively easy.
Firefox advocates/users who have been acting as if things like tabbed browsing, ad blocking, and so on, are huge, difficult, quantum leaps...they've been deluding themselves. Firefox has always come across as IE + some extra niceties. That's why I use it.
The Apple II wasn't 'OS-less' by any stretch of the imagination. It used either Apple DOS or Apple ProDOS as its OS, depending upon which machine and applications you were talking about. I don't know much about the architecture of the C64, but I'll bet it was hardly 'OS-less'.
You can consider the Apple II to be OS-less. When your code was running, absolutely nothing interfered with it. No other processes were running. You could write to any memory address you wanted. You put graphics up on the screen by writing directly to the memory associated with it. What the Apple II did have was a set of utility routines, either in ROM or loaded from the DOS boot disk. But you could live just fine without those routines if you chose to do so.
The Atari 800, to give another example, had a little mini-OS that was essentially there to provide services for BASIC and other language environments: simple screen I/O, simple copying of values from RAM to hardware registers during the vertical blank (to allow POKE-ing in BASIC without mid-frame flicker). Things like that. But you could just as easily take over the whole machine and do whatever you wanted, and that was common, because the OS services did nothing useful for you most of the time.
The key is to get something light, compact, cool running, good battery life, and yet still have good enough performance to be acceptable for most things. The goal is not by any means to have the fastest computer out there. Remember, if you really need the ultimate performance, you can always by a desktop. Or you could have just bought one of the current model PowerBooks instead of an iBook (though it's still not in the same ballpark as a high-end desktop). If you think about it, a 1.4GHz G4 with 3D acceleration standard, well, that's a pretty good machine for most things. Thinking back a few years, I developed commercial 3D games with desktops that were much lower powered than that. (For a real laugh, go back and look at what John Carmack used to develop Quake, remembering that Quake 1 was initially software rendering only.)
Realistically, the iBook is not a hardcore gaming machine. You're not going to find many PCs in the same price range that can play DOOM 3 with all the bells and whistles turned on either. And I'd argue that this is okay. High-end 3D games like this are a niche.
In terms of CoreImage, I think many people don't understand what it is. It is not QuartzExtreme. All 2D graphics are going through OpenGL on the iBook, so things will be snappy and take advantage of the GPU. CoreImage is about what are essentially Photoshop filters and special effects, not fundamental rendering. And being a fairly new OS X technology, it's not clear how much CoreImage is actually being used right now, or if it will come into its own in the future.
In fact, no one should need a computer over 1GHz! Therefore, we should not make power supplies or parts that are meant to supply something over a simple processor, video/sound card, and hard drive.
That's the classic overreaction. But stop and think about it: a good many people are beefing up their machines to ridiculous levels--450W power supply, super high-end video card, 3.6GHz CPU, fancy add-on sound card, 2GB of RAM--simply so they get lightning frame rates in some upper crust 3D games. 95% of the time all of that hardware is just sitting there. Now it's true that a GPU uses less power when it's sitting idle, but there's still a significant increase in power draw by putting in all these components. This especially applies to CPUs, where the cutting edge models (like a 3.6GHz P4) use substantially more power than run-of-the-mill "really fast" models, like the 3.2GHz P4. Is the increase in power consumption worth it for the 12.5% increase in clock speed? Doubtful.
This is hard to get across unless you followed personal computer developments in those days, but there was a definite excitement surrounding the release of entirely new home computers in those days. The Atari 800, the Amiga, the Atari ST, the Commodore 64, the Macintosh. Think about it: the Amiga had a brand new OS, brand new graphics and sound hardware...it was stunningly different. That's nowhere near the same thing as an incremental video card upgrade that still works through DirectX or a Dell that just has some different numbers in terms of bus speed, CPU speed, memory, etc.
The mid-80s were exciting times. In 1984 the Mac was released. The Atari ST and Amiga in 1985. The Apple IIgs in 1986. Then the color Macintosh in 1987.
The last time I felt this in regard to consumer-level computers was when the Be-Box was first announced. Since then it's just when new game consoles come along.
That honor goes to Ole-Johan Dahl and Kristen Nygaard, the designers of Simula. Simula had a strong effect on both Kay and Smalltalk.
There's nothing about BF2 that wouldn't work just as well on a console. It doesn't push any kind of graphical limits. It would work great with a typical console controller. It's a great game, yes, but that has nothing to do with it being a PC title.
I don't understand why some people are so anti-console. Look at it this way: a console typically costs less than a flashy PC graphics card, so why not just get one and have fun with it? That doesn't mean you can't also play PC games. If you've been completely blowing off consoles, then you've been missing out on some wonderful gaming experiences.
Somebody who loves computer science, like myself. I will be a freshman in the fall studying computer science. Computer science is a very interesting topic to study and to research, which is what I intend to do once I'm done with college.
Do you mean you want to do academic research after you're done with college--or some kind of research anyway? Or are you wanting to get a job as a programmer?
Good: No wires.
Bad: Batteries. You have to buy them (and throw them away) or recharge them, and monitor when they need replacing/recharging. A wire is a much simpler solution.
As for technology trends, Jobs just stumbles. His single biggest mistake is not porting the MacOS to x86 back in 1984 so that IBM PC users could run the operating system.
That's a ballsy statement. Most obviously, the Mac was intended to be an appliance with fixed and integrated hardware, right down to the floppy being ejected under software control. And then of course the PC was a fairly lame duck in 1984: segmented memory, mice were nonexistent, poor graphics support (and certainly without the square aspect ratio of the Mac display), only the built-in speaker for sound, etc.
The transition from 68K to PPC was chaotic for both users and developers, and I see no reason it isn't going to be the same this time around.
Quite a few apps never made the transition back then, but you didn't know which ones would and which ones wouldn't until you had the benefit of hindsight. The ones that didn't ran via emulation layer, but you paid a huge performance price for those. You bought high-end and pricey hardware, only to have your apps run slower than hardware from years earler.
Transitions like this are also huge for smaller developers. We're just getting to the point where many third party apps and development tools work well under OS X. Now all of a sudden they've got to budget what could be a massive port. Sure, Rosetta, blah, blah, blah, but think about what the makers of native code Lisps for the Mac are going through right now, for example. Likely, quite a few projects will die out. What about Mike Hoare's excellent Mops environment, which generates PowerPC code natively? This is going to be rough.
Personally, I've been on the verge of buying either an iBook or PowerBook. Now I don't see any reason to buy what's going to be legacy technology. Apple has completely lost me here.
Okay, laugh at me in a few hours if Apple does switch to the x86, but I don't think it's doing to happen. The x86 is too backward, too much of an old-school PC processor, for the crowd that Apple has been courting of late. And they key point is that it isn't worth running *all* software through emulation for *years* just to make a crazy switch like this. The emulation issue will make Macs seem much slower than equivalent PCs, regardless of price.
It's going to be one of the following:
1. PowerPC chips manufactured by Intel, in an effort to bring down the price and increase the clock speed. This is the most likely option.
2. Itanium. Maybe. Possibly. Intel desperately wants Itanium to succeed ant it *does* give ultra high performance if you blow off the x86 emulation nonsense.
3. ARM. Some kind of low-power alternative for notebooks. Doubt it, though.
It could be Itanium. Or ARM. Honestly, I don't see Apple going x86, because of the whole "think different" attitude.
From a tech point of view, it would be a shame for Apple to switch from the beautiful PPC chips to the ugly duckling x86. Apple has been been making some top notch technical choices, resulting in lots of geek cred, with the PPC line and OS X, so I just can't see the x86 making sense here.
(Itanium is an interesting possibility, in that Intel knows that line of chips is floundering, so Apple could walk in and save the day.)
PC gaming is never going to go away. Simply put, there is an installed base of several hundred million users.
And yet console games outsell PC games by a huge margin. A console blockbuster like GTA sells 5+ million copies. A PC blockbuster like Half-Life 2 is lucky to hit a million (and there are hardly any games in the HL2 class on the PC).
Open the systems to anyone and everyone to develop new programs and make it easy to share those programs with other users. With the power these boxes have there are a lot of possibilities but as always the mainstream is going to play it safe and try to deliver only what they have experience with.
Of course, console games take 2+ years, $8+ million dollars, and 50+ people to develop. The majority of that goes into art creation time: models, textures, animation, levels, etc. This is outside the range of individuals, even a dedicated group on the internet.