That's only true over very short time-scales. India's GDP growth rate is 8.4%. Essentially that means $10 invested in the economy today is $15 you can spend, perhaps on food for the poor, five years from now.
The potential return on investment for India's space program is quite high. They're already making some inroads into the commercial launch market, and with further investment could become a major provider of low-cost commercial launch services. Modest investments today could lead to getting a good portion of the $3 billion launch industry, and a nice portion of the $90 billion commercial satellite industry. In the long term, that's going to feed far more people than would get fed by spending that money directly.
So after they feed their people today, what do they do tomorrow? Welfare is a luxury for countries who have enough money that they don't need to make hard choices between economic progress and social well-being. For a developing nation, spending money on welfare for today's population is a sure way to perpetuate poverty to future generations. Investing in the economy, on the other hand, at least gives the hope that fewer people in the future will need welfare, and moreover that the government will be able to better afford welfare for those who still do need it.
There is also something to be said for the importance of a nation having ambitions on the world stage. Let me use as an example Bangladesh, where my parents were born, and which I still visit on occasion. Bangladesh has no ambition as a nation. Bengalis have no national pride to speak of, aside from a generally provincial sense of moral superiority. Their poverty is something that doesn't just manifest itself in the lack of food on the table, but something that infects their very mindset. They accept the state of affairs in their country, the political corruption and the social instability, because they lack the pride to believe that they are entitled to something better. Of the various problems the country faces, this lack of pride is far worse than flooding or hunger or disease combined. India presents a very stark contrast. If you look at the villages of India, you'll see the same hunger and disease you see in the villages of Bangladesh. But Indians have a great pride in their country, and in its long history of civilization. Their ambition drives them to improve their economy, invest in their infrastructure, and preserve their democracy. It is this ambition that makes it likely that in another couple of generations, India won't have to choose between improving their country and feeding the hungry. There is no similar hope for Bangladesh.
Since PCIe 2.0 is electrically compatible, the transition is going to be more like the one between AGP versions (which happened quite quickly), rather than the transition from PCI to PCIe.
Re:Performance, anyone?
on
Lisp and Ruby
·
· Score: 1
- The.NET compilers are implemented in C#, the class libraries are implemented in C#, and the CLR is implemented mostly in C. - The STL has nothing to do with Microsoft, it was created by Alexander Stepanov while he was at SGI. - LINQ is the antithesis of Lisp. LINQ directly implements syntax necessary to support queries. The Lisp approach is to define a general macro language, which can be used to implement syntax extensions in a general manner.
Undoubtedly, Lisp is in a position to influence other designs. Lisp is a major language that pioneered a lot of important ideas, and it any new design can leverage those ideas. However, we're talking about actually using Lisp as an implementation language on a major product.
Re:Performance, anyone?
on
Lisp and Ruby
·
· Score: 1
Maybe, but not to the point where they'd be able to do a large-scale product in Lisp. There are literally thousands of developers working on something like Office. That's probably a substantial fraction of the number of experienced Lisp developers put together.
Re:Performance, anyone?
on
Lisp and Ruby
·
· Score: 1
I agree with you in general sentiment, in that given equally well-written Lisp and C code, and good compilers, I wouldn't count on the Lisp code being closer than a factor of two to the C code, though in many cases it'll be much closer. However, there are a few finer points:
1) I find it, in general, rather difficult to get excited over a factor of two in pure CPU performance these days. I/O is the bottleneck in a lot of code, and in a good Lisp implementation, I/O will be as fast as it is in C.
2) Good Lisp compilers are harder to come by than good C compilers. Allegro is good at both high-level and low-level optimizations. SBCL is great at high-level optimizations, but its code-generator is a bit creaky. If either got half the attention of Intel C++ or even GCC, they'd be substantially faster.
3) Its hard to write C code as well as Lisp code. I write the same code in Lisp in a fraction of the time it takes me to write it in C++. If performance is the goal, and in that extra time I can improve my algorithms, then Lisp still wins, constant factors aside.
4) You'll never face the situation where your Lisp just isn't fast enough. Most Lisp compilers can be cajoled into generating the same code as a C compiler by writing C-level code in Lisp. And if worse comes to worse, calling out to assembly for that critical routine is trivially easy. And with all that time you save on the 80% of your program that isn't performance sensitive, you can afford to do more low-level tuning of the 20% that is.
Re:Performance, anyone?
on
Lisp and Ruby
·
· Score: 1
It's not so much about learning Lisp as about what happens to you while you're learning Lisp. There are companies out there that understand the value of having a team of developers gel and produce the best work of their careers. Hard to quantify this for management though, you really need to have their trust.
Yes, there are certainly places where this works, but unfortunately they're pretty hard to come by. In my world (research engineering), code is as often as not written by engineers, not programmers. Engineers generally have neither the inclination nor the proclivity for quickly learning a new language in support of a project. Moreover, since a lot of that code is throw-away code (you don't care about the quality of the implementation since you just care about the output), its often developed on a compressed schedule that leaves no time for new techniques on the software engineering side of things.
I'd imagine the roadblocks exist in many other segments of programming. For example, alternative languages are hard to push in large corporations, where large groups of people with the same skillset need to be gathered, and some substantial level of turnover is expected. A big corporation like Microsoft needs to gather thousands of good programmers for a single product. It would be difficult to gather a thousand Lisp programmers, period, much less a thousand good ones.
Re:Performance, anyone?
on
Lisp and Ruby
·
· Score: 1
The basic problem for Lisp is inertia. I'm starting a project right now to work on air-traffic algorithms. In these sorts of research projects, the usual "design -> implement" methodology goes out the window. Instead, you get a loop between design and implementation. You pick some initial algorithms, implement them, simulate the system, use the results of simulation to improve the algorithms, and repeat. Having worked on such a project in C++ for several years, I can tell you that C++ is just not great for such tasks. Lisp, on the other hand, excels at such tasks, because of how rapidly code can be changed, and how quickly prototypes can be mutated into final implementations.
In an ideal world, I'd do this project in Lisp, hands-down. But the world is not ideal. I'm the only one on the team experienced in Lisp, and we've got a tight deadline with no time for training in the implementation language. Then there are considerations about what happens when I leave, or when the code gets passed to another team to work with. Its a self-perpetuating cycle --- people don't know Lisp because people don't use Lisp; people don't use Lisp because people don't know Lisp.
The standard library issue is also another problem, but it's secondary to the basic issue of the lack of a large Lisp talant pool and the lack of strong commercial support.
Re:Performance, anyone?
on
Lisp and Ruby
·
· Score: 1
A good Lisp implementation is probably an order of magnitude faster than Lua.
We have a good idea that the CPU and GPU are very similar architecturally to their predecessors. If Nintendo really had made extensive changes to the chips, they would've done things like boost the amount of 1T-SRAM on the system. The fact that they boosted the amount of external DDR instead indicates that they didn't try to muck with the memory controller to much. The fact that they didn't enlarge the EDRAM on the GPU indicates that they worked on the GPU die conservatively, not wanting to change the load-store pipeline too much.
So while it's possible that certain effects on the Wii are much faster, I'd still say it's a stretch to call the console much more than twice as fast when it still basically has the same design. And of course 2x the raw theoretical power (which would be achieved if they increased the clock by 50% and say increased the number of pixel pipelines by 50%) still doesn't translate into anywhere near 2x the actual performance.
Actually, Nintendo *did* drive developers away during and after the SNES. Third-party developers got increasingly angry with Nintendo's heavy-handed policies during the SNES era, and when the N64 came out both late and with the cartridge format, they jumped ship to the Playstation.
At this point, Microsoft has scored some victories with getting some cross-platform titles, and a few titles from small publishers that are finding the 360 world to be less crowded, but for the most part, Sony's third-party developers are staying put. We aren't seeing anything like the rapidly-dwindling future lineup we saw with the N64.
It all comes down to the games. Before the launch of the PS3, people were saying they wanted it because they wanted the same experience they got with the PS2 and the PS1, namely the huge library that had games in every genre and even created a few new ones. But it's looking more and more like that experience is going to be on a non-Sony system.
While that's certainly possible, I'd still say that it's far from likely. After a year on the market, the 360 is still essentially dead in Japan. A lot of people dismiss this by pointing to the fact that the US market is twice as big as the Japanese market. On the other hand, it should be borne in mind that a large fraction of the top video game publishers are Japanese. The other thing to keep in mind is that Nintendo is ignoring a large part of the market in order to solidify their niche. The Wii hardware just isn't appropriate for many flagship titles, which are expected to not only excel in gameplay, but in graphics as well. You're just not going to be able to make the next Gears of War or the Gran Turismo or the next Final Fantasy on the Wii.
Clearly Sony has its work cut out for it. However, the market is still their's to lose (the PS2 was the holiday sales winner for yet another year this season). They've got the advantage that they're only competing with Microsoft on the high-end, and that they've got a strong low-end product to ride them through the launch problems with the PS3. They've also got the advantage that Microsoft's presence in their domestic market is essentially nil, and that their only other competitor domestically seems to be aiming at a different demographic.
In constrast, I couldn't be more pleased. My 5lb Macbook gives my 40lb PowerMac a beating on integer codes, despite the fact that the latter has a 15% clockspeed advantage (2.3 GHz 970MP), 60% more memory bandwidth, and nearly triple the watts to play with.
IBM's target is to double the performance of POWER5+ with this chip. If by "double the performance", they mean 2x the SPECint for the POWR5+, then that'd put the IPC of this new chip a little below the POWER5+, a little above the Opteron, and substantially behind the Core 2.
Actually, these POWER chips are very similar to the PowerPC chips used in Apple computers. The G5 has a POWER4 core with a different memory controller and I/O interface. The simple fact is that these POWER cores are great for applications which can leverage the fast SMP fabric, the huge caches, or large amounts of bandwidth, but are not necessarily great for when you need high performance for sequential code.
Your statement that these cores are "overkill" for Apple's target market is rather inaccurate. In SPECint, which was designed to measure these sorts of workstation workloads, the POWER chips get beaten quite handily by consumer-level x86 cores, for the simple reason that workstation tasks is exactly what these x86 chips were designed to do. So the POWER chips are inappropriate for Apple not just because they're too big and hot, but because they don't perform as well at workstation tasks.
This is absolutely the right thing. It's all about designing for the task. Apple doesn't care how fast Power6 is. Power6 is well over twice the size of Core 2, and has double the power dissipation at the highest clockspeed. Even in the most cut-down configuration, with one memory controller disabled, the other running at 1/2 width, and the I/O busses running at 1/4 width, it requires a motherboard with the I/O connectivity of an Opteron server board combined with the memory bus of a Xeon server board. Power6 is pushing it even for the PowerMac, much less the rest of Apple's product line.
What Apple needs is high-performance, but geared for its target market. That's what Intel offers: a high-performance chip that achieves that performance with consumer-grade infrastructure.
The current version fo SPECint really can't take advantage of anything bigger than a 4MB L2 cache. On the other hand, it should be noted that those POWER5 numbers are with IBM's XLC compilers, which are a lot better relative to GCC on PowerPC than Intel's C compiler is relative to GCC on x86. Also, POWER5 is very sensitive to workload and instruction ordering, so you're going to see lesser performance a lot more often than with Core, which is designed to handle the huge variety of poorly-scheduled code floating around in x86-land.
The Power line hasn't outperformed Intel per clock since the Pentium 4, if you discount applications where the server-sized L3 cache and memory bus of the POWER series comes into play.
In SPECint*, the G5's per-GHz performance is in the P4 range, maybe a little bit higher. Core 2's per-GHz performance is about 80% higher than that.
In general, more GHz means more performance for every processor, all else being equal. Any given design is the product of a set of trade-offs. Power is traded versus clockspeed, IPC is traded versus die-area and clockspeed, etc. Power6 achieves high performance via very aggressive circuit design that allows high clockspeed without trading off too much IPC, at the cost of die-area and power dissipation. Meanwhile, Core2 achieves high performance via very deep out-of-order execution, which allows high-IPC, with low power consumption, at the cost of clockspeed. Both designs are entirely valid ones for their respective tasks.
*) SPECint scales very well with clockspeed, so score/GHz is a pretty valid measure of efficiency.
RAII only solves the resource management problem for a small class of resources: those with dynamic extent. However, many objects need to have indefinite extent. Consider a C compiler. RAII is appropriate for a file handle in a function that opens a file, reads in the source code, and immediately closes the file. However, its completely inappropriate for the nodes of the abstract syntax tree that it creates from that source code, and passes to the rest of the compiler.
That's why C++ has smart pointers --- it handles the resource allocation problem for objects with indefinite extent (at a substantial cost in performance, btw). It's also why every non-trivial piece of C code has one (or more!) reference-counting mechanisms in place. In practice, GC is much simpler, and usually faster, than these ad-hoc mechanisms.
The non-determinism is orthogonal to GC versus malloc(). Neither of those mechanisms are deterministic. In order to write a time-critical handler in a GC'ed language, you do the same thing you do to write a time-critical handler in C: allocate from a fixed reserve pool of memory. Note that this should almost always be an applicable technique, for the simple reason that its rare to have a function with fixed time-bounds but variable space-bounds.
Take something like an interrupt handler. In the Linux kernel, you can't sleep in a bottom-half. All the memory allocation primitives sleep by default, so you have to call kmalloc() with GFP_ATOMIC. GFP_ATOMIC services the request from a pool of reserved memory, and fails if that memory is exhausted. In a kernel written in a GC'ed language, you could do the same thing. Grab some objects from the GC at startup, and grab one of those objects in the trap handler instead of calling the GC and potentially invoking a collection.
1) Most good OOP languages (C++ is not one of them) do type inference to statically resolve method dispatch when possible. This can either happen at compile-time or runtime depending on the implementation. 2) Clever implementation techniques can do partial dispatch optimizations that turn indirect calls into decision tree when it can be determined that the target will always be a member of a specific set of types. 3) Modern CPUs (both K8L and Core 2) have indirect branch predictors that'll predict data-dependent branches like those involved in indirect function calls. 4) Indirect calls are very often necessary even in C. Look how many function pointers are floating around the Linux kernel, for example (or any kernel, for that matter).
Really high-performance implementations of object-oriented languages (things like Concurrent Aggregates, Self, Strongtalk, Orbit) that perform very competitively with C. Even with today's generation of native-code compilers for OO languages, you can almost always get within 50% the performance of C, and often within 20%. And if you're writing code where a factor of two in a tight loop is going to be a deal breaker, then you're at the point where you're going to want to break out the assembly anyway.
In modern implementations of highly-OOP languages like Lisp, Dylan, and Scheme, the bottleneck is more often the actual machine-code generator than the object-orientation infrastructure. I use SBCL a lot (a native-code Lisp compiler), and if you gave me the option of a perfect type-inferencer that removed OO overhead, or a low-level optimizer that generated machine-code as good as Intel C's, I'd pick the latter.
Bounds-checking in C is complicated to implement (read the limitations imposed on code on the page you referenced), and slow too. Bounds-checking a language with proper arrays is very cheap --- a simple limit check that can be issued in parallel with the load from the array. On a modern superscaler CPU (which has tons of idle issue slots most of the time), it costs you 2-3% even in tight loops. In comparison, deal with bounds-checking in a language with pointers requires inserting bits of padding everywhere and checking their validity on each pointer access. It's much more expensive both in space and in time.
C and C++ are actually a very large step away from assembly language, and are probably closer to Java than to assembly. The memory model of C is moderately close to assembly, though it hides registers and memory ordering instructions. However, the execution model is completely different. It abstracts branches, function calls, the runtime stack, not to mention things like branch hints, etc.
Once you've got C, you've got functions, function (direct and indirect), variables, conditionals, loops, types, type-checking, variables, etc. What does Java add on top of that? Classes, more type safety, another abstraction over indirect function calls (method calls), and some synactical suger like foreach (in recent versions). Put another way: its a lot more work to write a C to assembly compiler than modify a C compiler to compile Java (standard library aside).
Slashdot Mirror
That's only true over very short time-scales. India's GDP growth rate is 8.4%. Essentially that means $10 invested in the economy today is $15 you can spend, perhaps on food for the poor, five years from now.
The potential return on investment for India's space program is quite high. They're already making some inroads into the commercial launch market, and with further investment could become a major provider of low-cost commercial launch services. Modest investments today could lead to getting a good portion of the $3 billion launch industry, and a nice portion of the $90 billion commercial satellite industry. In the long term, that's going to feed far more people than would get fed by spending that money directly.
So after they feed their people today, what do they do tomorrow? Welfare is a luxury for countries who have enough money that they don't need to make hard choices between economic progress and social well-being. For a developing nation, spending money on welfare for today's population is a sure way to perpetuate poverty to future generations. Investing in the economy, on the other hand, at least gives the hope that fewer people in the future will need welfare, and moreover that the government will be able to better afford welfare for those who still do need it.
There is also something to be said for the importance of a nation having ambitions on the world stage. Let me use as an example Bangladesh, where my parents were born, and which I still visit on occasion. Bangladesh has no ambition as a nation. Bengalis have no national pride to speak of, aside from a generally provincial sense of moral superiority. Their poverty is something that doesn't just manifest itself in the lack of food on the table, but something that infects their very mindset. They accept the state of affairs in their country, the political corruption and the social instability, because they lack the pride to believe that they are entitled to something better. Of the various problems the country faces, this lack of pride is far worse than flooding or hunger or disease combined. India presents a very stark contrast. If you look at the villages of India, you'll see the same hunger and disease you see in the villages of Bangladesh. But Indians have a great pride in their country, and in its long history of civilization. Their ambition drives them to improve their economy, invest in their infrastructure, and preserve their democracy. It is this ambition that makes it likely that in another couple of generations, India won't have to choose between improving their country and feeding the hungry. There is no similar hope for Bangladesh.
If this was last year, he was likely talking about the older (P4-based) Xeon, not the new (Core 2-based) Xeon.
Since PCIe 2.0 is electrically compatible, the transition is going to be more like the one between AGP versions (which happened quite quickly), rather than the transition from PCI to PCIe.
- The .NET compilers are implemented in C#, the class libraries are implemented in C#, and the CLR is implemented mostly in C.
- The STL has nothing to do with Microsoft, it was created by Alexander Stepanov while he was at SGI.
- LINQ is the antithesis of Lisp. LINQ directly implements syntax necessary to support queries. The Lisp approach is to define a general macro language, which can be used to implement syntax extensions in a general manner.
Undoubtedly, Lisp is in a position to influence other designs. Lisp is a major language that pioneered a lot of important ideas, and it any new design can leverage those ideas. However, we're talking about actually using Lisp as an implementation language on a major product.
Maybe, but not to the point where they'd be able to do a large-scale product in Lisp. There are literally thousands of developers working on something like Office. That's probably a substantial fraction of the number of experienced Lisp developers put together.
I agree with you in general sentiment, in that given equally well-written Lisp and C code, and good compilers, I wouldn't count on the Lisp code being closer than a factor of two to the C code, though in many cases it'll be much closer. However, there are a few finer points:
1) I find it, in general, rather difficult to get excited over a factor of two in pure CPU performance these days. I/O is the bottleneck in a lot of code, and in a good Lisp implementation, I/O will be as fast as it is in C.
2) Good Lisp compilers are harder to come by than good C compilers. Allegro is good at both high-level and low-level optimizations. SBCL is great at high-level optimizations, but its code-generator is a bit creaky. If either got half the attention of Intel C++ or even GCC, they'd be substantially faster.
3) Its hard to write C code as well as Lisp code. I write the same code in Lisp in a fraction of the time it takes me to write it in C++. If performance is the goal, and in that extra time I can improve my algorithms, then Lisp still wins, constant factors aside.
4) You'll never face the situation where your Lisp just isn't fast enough. Most Lisp compilers can be cajoled into generating the same code as a C compiler by writing C-level code in Lisp. And if worse comes to worse, calling out to assembly for that critical routine is trivially easy. And with all that time you save on the 80% of your program that isn't performance sensitive, you can afford to do more low-level tuning of the 20% that is.
It's not so much about learning Lisp as about what happens to you while you're learning Lisp. There are companies out there that understand the value of having a team of developers gel and produce the best work of their careers. Hard to quantify this for management though, you really need to have their trust.
Yes, there are certainly places where this works, but unfortunately they're pretty hard to come by. In my world (research engineering), code is as often as not written by engineers, not programmers. Engineers generally have neither the inclination nor the proclivity for quickly learning a new language in support of a project. Moreover, since a lot of that code is throw-away code (you don't care about the quality of the implementation since you just care about the output), its often developed on a compressed schedule that leaves no time for new techniques on the software engineering side of things.
I'd imagine the roadblocks exist in many other segments of programming. For example, alternative languages are hard to push in large corporations, where large groups of people with the same skillset need to be gathered, and some substantial level of turnover is expected. A big corporation like Microsoft needs to gather thousands of good programmers for a single product. It would be difficult to gather a thousand Lisp programmers, period, much less a thousand good ones.
The basic problem for Lisp is inertia. I'm starting a project right now to work on air-traffic algorithms. In these sorts of research projects, the usual "design -> implement" methodology goes out the window. Instead, you get a loop between design and implementation. You pick some initial algorithms, implement them, simulate the system, use the results of simulation to improve the algorithms, and repeat. Having worked on such a project in C++ for several years, I can tell you that C++ is just not great for such tasks. Lisp, on the other hand, excels at such tasks, because of how rapidly code can be changed, and how quickly prototypes can be mutated into final implementations.
In an ideal world, I'd do this project in Lisp, hands-down. But the world is not ideal. I'm the only one on the team experienced in Lisp, and we've got a tight deadline with no time for training in the implementation language. Then there are considerations about what happens when I leave, or when the code gets passed to another team to work with. Its a self-perpetuating cycle --- people don't know Lisp because people don't use Lisp; people don't use Lisp because people don't know Lisp.
The standard library issue is also another problem, but it's secondary to the basic issue of the lack of a large Lisp talant pool and the lack of strong commercial support.
A good Lisp implementation is probably an order of magnitude faster than Lua.
We have a good idea that the CPU and GPU are very similar architecturally to their predecessors. If Nintendo really had made extensive changes to the chips, they would've done things like boost the amount of 1T-SRAM on the system. The fact that they boosted the amount of external DDR instead indicates that they didn't try to muck with the memory controller to much. The fact that they didn't enlarge the EDRAM on the GPU indicates that they worked on the GPU die conservatively, not wanting to change the load-store pipeline too much.
So while it's possible that certain effects on the Wii are much faster, I'd still say it's a stretch to call the console much more than twice as fast when it still basically has the same design. And of course 2x the raw theoretical power (which would be achieved if they increased the clock by 50% and say increased the number of pixel pipelines by 50%) still doesn't translate into anywhere near 2x the actual performance.
Actually, Nintendo *did* drive developers away during and after the SNES. Third-party developers got increasingly angry with Nintendo's heavy-handed policies during the SNES era, and when the N64 came out both late and with the cartridge format, they jumped ship to the Playstation.
At this point, Microsoft has scored some victories with getting some cross-platform titles, and a few titles from small publishers that are finding the 360 world to be less crowded, but for the most part, Sony's third-party developers are staying put. We aren't seeing anything like the rapidly-dwindling future lineup we saw with the N64.
It all comes down to the games. Before the launch of the PS3, people were saying they wanted it because they wanted the same experience they got with the PS2 and the PS1, namely the huge library that had games in every genre and even created a few new ones. But it's looking more and more like that experience is going to be on a non-Sony system.
While that's certainly possible, I'd still say that it's far from likely. After a year on the market, the 360 is still essentially dead in Japan. A lot of people dismiss this by pointing to the fact that the US market is twice as big as the Japanese market. On the other hand, it should be borne in mind that a large fraction of the top video game publishers are Japanese. The other thing to keep in mind is that Nintendo is ignoring a large part of the market in order to solidify their niche. The Wii hardware just isn't appropriate for many flagship titles, which are expected to not only excel in gameplay, but in graphics as well. You're just not going to be able to make the next Gears of War or the Gran Turismo or the next Final Fantasy on the Wii.
Clearly Sony has its work cut out for it. However, the market is still their's to lose (the PS2 was the holiday sales winner for yet another year this season). They've got the advantage that they're only competing with Microsoft on the high-end, and that they've got a strong low-end product to ride them through the launch problems with the PS3. They've also got the advantage that Microsoft's presence in their domestic market is essentially nil, and that their only other competitor domestically seems to be aiming at a different demographic.
It's not quite twice was powerful as the original GC.
In constrast, I couldn't be more pleased. My 5lb Macbook gives my 40lb PowerMac a beating on integer codes, despite the fact that the latter has a 15% clockspeed advantage (2.3 GHz 970MP), 60% more memory bandwidth, and nearly triple the watts to play with.
IBM's target is to double the performance of POWER5+ with this chip. If by "double the performance", they mean 2x the SPECint for the POWR5+, then that'd put the IPC of this new chip a little below the POWER5+, a little above the Opteron, and substantially behind the Core 2.
Actually, these POWER chips are very similar to the PowerPC chips used in Apple computers. The G5 has a POWER4 core with a different memory controller and I/O interface. The simple fact is that these POWER cores are great for applications which can leverage the fast SMP fabric, the huge caches, or large amounts of bandwidth, but are not necessarily great for when you need high performance for sequential code.
Your statement that these cores are "overkill" for Apple's target market is rather inaccurate. In SPECint, which was designed to measure these sorts of workstation workloads, the POWER chips get beaten quite handily by consumer-level x86 cores, for the simple reason that workstation tasks is exactly what these x86 chips were designed to do. So the POWER chips are inappropriate for Apple not just because they're too big and hot, but because they don't perform as well at workstation tasks.
This is absolutely the right thing. It's all about designing for the task. Apple doesn't care how fast Power6 is. Power6 is well over twice the size of Core 2, and has double the power dissipation at the highest clockspeed. Even in the most cut-down configuration, with one memory controller disabled, the other running at 1/2 width, and the I/O busses running at 1/4 width, it requires a motherboard with the I/O connectivity of an Opteron server board combined with the memory bus of a Xeon server board. Power6 is pushing it even for the PowerMac, much less the rest of Apple's product line.
What Apple needs is high-performance, but geared for its target market. That's what Intel offers: a high-performance chip that achieves that performance with consumer-grade infrastructure.
The current version fo SPECint really can't take advantage of anything bigger than a 4MB L2 cache. On the other hand, it should be noted that those POWER5 numbers are with IBM's XLC compilers, which are a lot better relative to GCC on PowerPC than Intel's C compiler is relative to GCC on x86. Also, POWER5 is very sensitive to workload and instruction ordering, so you're going to see lesser performance a lot more often than with Core, which is designed to handle the huge variety of poorly-scheduled code floating around in x86-land.
The Power line hasn't outperformed Intel per clock since the Pentium 4, if you discount applications where the server-sized L3 cache and memory bus of the POWER series comes into play.
In SPECint*, the G5's per-GHz performance is in the P4 range, maybe a little bit higher. Core 2's per-GHz performance is about 80% higher than that.
In general, more GHz means more performance for every processor, all else being equal. Any given design is the product of a set of trade-offs. Power is traded versus clockspeed, IPC is traded versus die-area and clockspeed, etc. Power6 achieves high performance via very aggressive circuit design that allows high clockspeed without trading off too much IPC, at the cost of die-area and power dissipation. Meanwhile, Core2 achieves high performance via very deep out-of-order execution, which allows high-IPC, with low power consumption, at the cost of clockspeed. Both designs are entirely valid ones for their respective tasks.
*) SPECint scales very well with clockspeed, so score/GHz is a pretty valid measure of efficiency.
RAII only solves the resource management problem for a small class of resources: those with dynamic extent. However, many objects need to have indefinite extent. Consider a C compiler. RAII is appropriate for a file handle in a function that opens a file, reads in the source code, and immediately closes the file. However, its completely inappropriate for the nodes of the abstract syntax tree that it creates from that source code, and passes to the rest of the compiler.
That's why C++ has smart pointers --- it handles the resource allocation problem for objects with indefinite extent (at a substantial cost in performance, btw). It's also why every non-trivial piece of C code has one (or more!) reference-counting mechanisms in place. In practice, GC is much simpler, and usually faster, than these ad-hoc mechanisms.
The non-determinism is orthogonal to GC versus malloc(). Neither of those mechanisms are deterministic. In order to write a time-critical handler in a GC'ed language, you do the same thing you do to write a time-critical handler in C: allocate from a fixed reserve pool of memory. Note that this should almost always be an applicable technique, for the simple reason that its rare to have a function with fixed time-bounds but variable space-bounds.
Take something like an interrupt handler. In the Linux kernel, you can't sleep in a bottom-half. All the memory allocation primitives sleep by default, so you have to call kmalloc() with GFP_ATOMIC. GFP_ATOMIC services the request from a pool of reserved memory, and fails if that memory is exhausted. In a kernel written in a GC'ed language, you could do the same thing. Grab some objects from the GC at startup, and grab one of those objects in the trap handler instead of calling the GC and potentially invoking a collection.
You're neglecting four things:
1) Most good OOP languages (C++ is not one of them) do type inference to statically resolve method dispatch when possible. This can either happen at compile-time or runtime depending on the implementation.
2) Clever implementation techniques can do partial dispatch optimizations that turn indirect calls into decision tree when it can be determined that the target will always be a member of a specific set of types.
3) Modern CPUs (both K8L and Core 2) have indirect branch predictors that'll predict data-dependent branches like those involved in indirect function calls.
4) Indirect calls are very often necessary even in C. Look how many function pointers are floating around the Linux kernel, for example (or any kernel, for that matter).
Really high-performance implementations of object-oriented languages (things like Concurrent Aggregates, Self, Strongtalk, Orbit) that perform very competitively with C. Even with today's generation of native-code compilers for OO languages, you can almost always get within 50% the performance of C, and often within 20%. And if you're writing code where a factor of two in a tight loop is going to be a deal breaker, then you're at the point where you're going to want to break out the assembly anyway.
In modern implementations of highly-OOP languages like Lisp, Dylan, and Scheme, the bottleneck is more often the actual machine-code generator than the object-orientation infrastructure. I use SBCL a lot (a native-code Lisp compiler), and if you gave me the option of a perfect type-inferencer that removed OO overhead, or a low-level optimizer that generated machine-code as good as Intel C's, I'd pick the latter.
Bounds-checking in C is complicated to implement (read the limitations imposed on code on the page you referenced), and slow too. Bounds-checking a language with proper arrays is very cheap --- a simple limit check that can be issued in parallel with the load from the array. On a modern superscaler CPU (which has tons of idle issue slots most of the time), it costs you 2-3% even in tight loops. In comparison, deal with bounds-checking in a language with pointers requires inserting bits of padding everywhere and checking their validity on each pointer access. It's much more expensive both in space and in time.
C and C++ are actually a very large step away from assembly language, and are probably closer to Java than to assembly. The memory model of C is moderately close to assembly, though it hides registers and memory ordering instructions. However, the execution model is completely different. It abstracts branches, function calls, the runtime stack, not to mention things like branch hints, etc.
Once you've got C, you've got functions, function (direct and indirect), variables, conditionals, loops, types, type-checking, variables, etc. What does Java add on top of that? Classes, more type safety, another abstraction over indirect function calls (method calls), and some synactical suger like foreach (in recent versions). Put another way: its a lot more work to write a C to assembly compiler than modify a C compiler to compile Java (standard library aside).