Sure. It is not really that relevant though, one could in theory build a compeltely different desktop on top of the NT kernel, but here we are rather having an issue with the meaning of 'Operating System' in different cultures.
For Windows, OSX, and most other systems (BeOS, Syllable, etc.) 'Operating System' refers to a large software stack, the kernel plus a platform SDK and some environment in which the whole thing is hosted (the desktop). In classic Unix/Linux terminology the OS is pretty much a kernel and a very small portion of the userland (/bin; ls and rm and such). Sun is a nice example, they call the distribution of Solaris an 'Operating Environment' built on their OS SunOS.
This works out fine with my post, if we take the Linux/UNIX interpretation of 'OS' nothing at all in Windows depends on IE at all, it is completely associated with the desktop running on top of Windows. With the more normal terminology however IE is integrated since you don't go off and replace the desktop, and the desktop includes the IE rendering engine in the platform SDK.
Whether IE is good or not is hardly relevant to the post as such, the good news however is that PNG support is complete in IE7, as well as improved CSS (though no CSS3).
Of course the rendering engine is not actually named IE. It just so happens that that is the name that people know it by and which makes sense to discuss in this type of forum. As it happens IE itself (rendering engine not included) is not integrated in any way at all, any application that hosts the rendering engine can handle the tasks normally considered IE-specific (Windows Update for example) so that makes the point even more moot.
Feel free to read my original post substituting 'IE' with 'Trident' however, the point of the post is the same.
Windows should not really die a fiery death from IE dissappearing, and most likely things like explorer.exe dying and so on are rather signs that something has gone more wrong than that (that is, it manages to invoke something that wrecks havoc on the system, rather than just not finding the rendering engine).
In the same way Konqueror could with the proper slightly-malicious code injected hose KDE fairly well (run off and allocate KParts modules like mad or so), but normally wont.
Microsofts code no doubt has issues here and there, but it is not really a fundamental error on Microsofts part that causes a lot of spyware to wreck things once it gets on the system (whether microsoft is to blame for the spyware getting there to start with is a different matter though).
How often do we have to go through this? IE is integral to the platform in the same way Konqueror/KHTML is to KDE. It is part of the standard libraries/components and applications can expect it to be available to view richly formatted data. It is not a deep kernel integration or any of those wacky Slashdot conspiracy theories, it is just an example of good old software reuse.
I don't think anyone can actually suggest that Microsoft throw it out, having a good rendering engine of type in the platform SDK is pretty much a requirement these days. The OSS desktops all leveraging HTML engines is just one example, check out Apple who are relly going at it building applications based on WebCore. It just so happens that Microsoft got into the game early (one could in fact use the word "innovation" here, but I guess that would be a bit too flamebaity on Slashdot).
CS, computer engineering, whichever. It is all under the same general umbrella, I too meant to imply that whatever student group happens to be best at logic design still can't put together a chip on the level of the R10000 just like that.
Graduate student projects can often be fairly interesting and impressive, but you very deeply underestimate the work involved here. To put it this way; Academic projects are often very clever in a fundamental way, but commercial designs have year after year of very clever work done on every detail. This is not interesting to academia since it proves nothing about the design as such, it just creates a good end product.
I do recognize this myself though, I am often of a similar opinion about great pieces of software (I am firmly on the software side of things actually, though I have written some VHDL and have a general interest in computer architecture). It is easy to look at the fundamentals and say "the basic workings of this is trivial", but the devil is always in the details.
But, anyway, this story has long since dissappeared from the frontpage, lets get on with out lives.
If it is like the R10000 in technology, not bloody likely that just about anyone can put one together. It was a very neat superscalar OoO-chip that is still looking good today.
I don't get the reference to Hennesy and Patterson at all here, while they do indeed discuss the implementation of pipelined chips with the Mips as the running example they do it on a high level. Doing an efficient implementation of even only the parts discussed in the book requires doing the actual clever implementation work of large portions of logic not really touched upon. Even things that are discussed are in so general terms that the books worth as a practical guide to actually building a modern chip is fairly low (it is an introductionary book after all). In addition they don't even discuss the issues involved in a chip of this level, notable missing parts are OoO logic and the FPU and so on (again understandable since it is an introduction).
Don't compare the R10000 to the stuff that a CS class hobbles together (which also tends to be a very small portion of a complete chip), it is an insult to all of computer architecture if anything.
So, the R10000 was very much state of the art in 1995, and is still doing fairly well today (the R160000 is pretty much the same core, just shrunk and tuned). If China has made an equivalent it is proof enough that they can make a competitive chip.
Google Groups non-usenet functionality is quite a bit younger than Yahoo Groups though (quite old community solution really). Also Google Groups features a quite confusing interface ever since the remake (and the remake was what added the non-usenet groups).
This is just a report about the general issue that all USB drivers have to be secure or a hardware device can be made to exploit the machine. It is in no way about Windows, but actually about any operating system than implements USB.
Sadly enough it is not at all suprising that Slashdot immediately goes for the anti-Windows slant rather than actually reading and comprehending the article and exploit in question. Too few actual axploits in Windows as of late to get up to the required quota perhaps?
In a more direct comment about the "exploit" I don't consider it terribly important, hardware access leads to a lot of trivial expoits. This one can be made more user-friendly than most with appropriate hardware, but it is not really worse than just inserting a boot CD that copies the relevant data to a secure server or so. It can also of course easily be fixed by disallowing loading of USB drivers without confirmation from the user.
Its like saying C was an incredibly original language. No, it was based heavily on the procedural language theory; PASCAL (ugh) could be considered genuinely original.
I think you meant to say ALGOL. Few technological innovations have managed to simultaneously be so incredibly influential and obscure, not even Smalltalk really gets close. The quick summary is this; Algol is the language that inspired newer variations like C and Pascal.
Then I have good news for you (though you should have noticed it yourself); g++ performance is improving by leaps and bounds as of late.
The new hand-written recursive descent parser added in 3.4 improved performance a fair bit (making 3.4 the fastest g++ version ever as of the release they claim). The performance for compiling without optimization was improved even more in 4.0. For Gentoo users and other OCD-level recompilers it might not matter, but it does help developers everywhere. This is what I would personally call the place where it matters, end users that obsess over recompiling stuff themselves for no reason can wait.
It is overall a general consensus among gcc developers that performance should be improved. Don't expect C-level compilation speeds from C++ though, it is a heavy language to compile by nature. This keeps getting worse with the increasing prevalence of extreme template metaprogramming libraries like Boost, to a great part in meaningless areas in a quest for performance that will never matter or materialize (I don't claim that Boost or template metaprogramming is a bad thing, just that people obsessivly use it in places where normal coding practices would do just as well except for imagined performance/purity issues).
Yeah. It is a clearly bad thing and has to be fixed. On the other hand Microsoft will no doubt fix it (in a less timely fashion than OSS typically does, but they are a lot quicker than they used to).
In retrospect my message is a bit whiny, it is a real security concern, it is just that I have read one too many slightly slanted reports on Microsoft security on Slashdot the last few years. Microsoft does a lot better today than they did before their security push and I am very happy to see this. Even for people who hate Windows it has to be heartening to see it improve, at least considering that there are no signs of Microsoft going away any time soon.
No need to blow this out of proportion; from the article:
In an advisory posted at SecurityProtocols.com, the researcher described the issue as a remote kernel denial-of-service flaw affecting XP SP2, with the default firewall turned on.
I know Slashdot loves to hold Microsoft to golden standards, but a DOS-attack in a not overly important desktop daemon is hardly huge news. At the very least it happens to a lot of OS's a lot of the time.
Either that, or you can try not being a nerdy jackass. People will survive just fine on IE, Microsoft has really picked up the pace with patching and spyware is mostly from people installing things they should not (which they can do just as well with Firefox).
Don't pretend that this is the most important thing in the world. It isn't, and people rightly don't take much interest in it.
Yeah, as I said the G5 is a mean machine when it comes to linear performance. If you don't luck out and get ICC to generate some good SSE2/SSE3 for the P4 the G5 FPU's will beat the weak x87 in the P4 easily (which is also the K7 and K8's big ace, they have a far better x87 FPU implementation).
It is if one includes the vector performance that the P4 looks good, the x87 is more or less just thrown in for compatibility expecting applications to move to the SSE2/SSE3 units instead. And those are fast.
The Pentium 4 has gotten a bad reputation, to some part well-deserved since it did not work out the way Intel had hoped in many ways. In the way of innovation and willingness to push the envelope Intel really did a great job with the Pentium 4 however. Really pushing for extreme frequency scaling (for example one should remember here that the P4 ALU's actually run at double the clockrate even), doing away with the aging x87 in favor of newer more streamlined SIMD instructions and overall doing one hell of a design job on it.
Things did not pan out as expected however, newer processes did not bring the frequency improvements Intel had hoped for (power leakage turned out to be larger than expected), and Intel really had expected it. Have a look at all the extreme-cooling experiments that successfully push the P4 to clockrates of well in excess of 4GHz (meaning that the CPU timings really are streamlined, it is a power leakage issue). Also the RAMBUS debacle messed things up for Intel, making the tradeoffs in the P4's memory hierarchy a lot worse than originally intended.
This is not intended as an apologetic post with regard to the P4, it did not live up to the promises the design tried to make. It is however still a mean performer in the right settings, and this includes opportunity to make it really output the FLOPS. It is a bit of a step down for people who liked the G5's ease of use, but for the Mac community it is mostly a step back to the way things was with the G4 (more work to get the performance, but the performance is there).
And what are scientific computation people doing on either the G5 or P4 at this point anyway? Off you go to the K8 already:)
Actually you have it a bit backwards. The P4 is rather back to the roots for Apple, an excellent SIMD performer with a bit so-so performance on linear floating point. It was the initial issue with the P4, a weak x87 implementation with a great focus instead on the excellent performance of the SSE2 (and SSE3 with the prescott).
Compare this to the G4, another weak linear performer that Apple more or less specialized in getting to fly through good use of the excellent Altivec unit. The G5 on the other hand has a somewhat weak Altivec unit but a much beefed up set of single-element FPU units, yielding so-so vector performing but good linear performance. IBM did probably not focus much energy on the Altivec unit but instead threw it in since Apple required it (after all, the single-element FPU performance of the G5 almost puts the Altivec unit to shame).
Some might now be quick to point out that Altivec is a nicer instruction set than SSE2/SSE3, this is by most standards true, but if you are hand-coding assembly you can make do with either. On the flip side Intel has quite impressive auto-vectorization support in their compiler.
So, what does this add up to? The G5 is in a good place for beating the P4 on unoptimized unvectorized code, but the P4 really screams if things are tuned up a bit. Considering Apples history with Altivec I think we can safely assume that they won't be afraid of doing some hand-tuning to get good perfomance.
This all ends up looking quite favorable for the P4, I still don't think we will see a commercial Mac with a P4 derivative in it, but anyone who thinks the P4 is a weak performer has another thing coming. For a bit more on my opinion on the state of the x86 vs. PPC today see my earlier post in the "Apple Switch to Intel Not a Big Loss for IBM" story.
This thread has long since moved on, but I thought I'd clarify my position if someone happens to read it anyway.
Perl is also very large and complex, but what people tend to remember is the very terse syntax. Python has an insane number of language features piled up on it (and there is no sign of it stopping), all of them with fairly clear syntax, but it still makes the language as a whole very large (and with size comes complexity).
The code remains fairly easy to read, but the amount of syntax and semantics you have to learn to have a complete grasp just continues to increase, all in all it introduces power by having many specialized features, rather than for example C++ which introduces power by having a few very powerful concepts (templates) which can achieve a lot of different goals (in very obscure ways).
Lets just have a look at the latest release, Python 2.4:
- Decorators, a very non-ovious but fairly fundamental piece of syntax sugar (a function definition is preprended with a special syntax '@foo' causing the function to be bound as func = foo(func) rather than just 'func' as usual).
- For some insane reason Python is still working on unifying the arbitrary length arithmetic with the regular 32bit one, again changing the semantics of some operations (why wasn't this all done in one go?).
- Generator expressions. Basicly a special syntax for implementing lazy list comprehensions.
- Decimal data type. Would not be so major if Python wasn't a dynamically typed language, changing the type hierarchy in every other release (especially the numeric tower which is already messed up from the changes to the handling of arbitrary length arithmetic) is messy.
There are a lot more new in Python 2.4, but these are some of the more major changes. And this is with 2.3 having been released less than 1.5 years earlier. 2.4 is nothing special either, huge amounts of changes like these happen with every Python release. This lands us in some trouble, with tons of new syntax and semantics added to the core language in every release it is very hard to actually keep up or even worse, try to use different versions at the same time. It is also a very hard job for any newbie to get proficient with all the features of Python, meaning that one ends up having to spend a very long time before one can expect to understand other peoples code.
This one can contrast with most other languages, where the core language is not changed more often than perhaps once or twice per decade. They instead try to offer more powerful basic constructs and expect users to build from there. The Python approach has its advantages, but it is hard to dispute that the end result can not really be considered elegant.
Except x86 hell is a quite nice place to be these days. The PPC970 is neat, but it is far from obvious that it is a better choice than, say, the Athlon64.
People like to take shots at the x86, but it is hard to deny that there are brilliant people working on it, really making implementations that fly. Intel's development team has a long proud history (they pretty much single-handedly turned the perception of CISC/RISC around with the Pentium Pro after all), and the AMD K8 team looked suspiciously much like the Alpha team at one point.
That is not to say that the POWER4 and derivatives are not impressive, they are, but the performance of chips like the AMD K8 really proves that if you have a competent team small details like the ISA don't matter all that much. I see no easy way for IBM to sneak into China, and it is actually a good thing; We are all better off with:
- The x86, which has more healthy competition going on with several high-profile implementations well suited for desktop use.
- MIPS/ARM, widely licensed and implemented architectures. The architectures are even cleaner than the PPC and SPARC.
- The SPARC, completely open and royalty-free, lots of implementations. This includes a series of LGPL/GPL VHDL implementations from Gaisler Research.
By comparison the PPC would be a fairly serious case of lock-in, only two companies manufacture chips (Freescale/Motorola and IBM), and Freescale mostly bothers with embedded applications.
In summary, having some PPC around is nice, but having it take over a market would be a bad thing at this point.
Python elegant? That's just ridicolous. Python is a huge and complex lanuage. It has ridicolously many language features, with a bunch new ones added with each release. All with only little planning and thought. It happens to end up being fairly powerful, and of course extremely featureful, but absolutely not elegant.
C# and Java are both clearly more elegant designs, as is C really. C++ has a lot of syntax, and rather wacky semantics in parts, but it manages a lot of power with a few very important concepts (templates). Overall, in elegance I would probably rate Python second to last of the languages listed (VB is extremely unelegant). This does not mean that it is a bad language (though I personally don't care for it), it is powerful and featureful, but it pays for it by being a huge language.
I don't see any problem at all with this if it is indeed for all non-intel processors. Targeting a competitor directly by slowing things down is a bad thing, but putting in the simplest default fallback for any other processors than the one you are trying to optimize for seems like a very reasonable way to go. To put it this way; Intel makes a compiler optimized for their products, and they throw in a simple fallback to supply simple code that should work on any basic x86 compatible. If it can be demonstrated that the intent of this is to damage AMD it is a bad thing, but it seems more likely that Intel simply does not care about the performance of the compiler on any other implementation (and seeing how they by no means have a monopoly on compilers there is nothing wrong with that).
Slashdot Mirror
For Windows, OSX, and most other systems (BeOS, Syllable, etc.) 'Operating System' refers to a large software stack, the kernel plus a platform SDK and some environment in which the whole thing is hosted (the desktop). In classic Unix/Linux terminology the OS is pretty much a kernel and a very small portion of the userland (/bin; ls and rm and such). Sun is a nice example, they call the distribution of Solaris an 'Operating Environment' built on their OS SunOS.
This works out fine with my post, if we take the Linux/UNIX interpretation of 'OS' nothing at all in Windows depends on IE at all, it is completely associated with the desktop running on top of Windows. With the more normal terminology however IE is integrated since you don't go off and replace the desktop, and the desktop includes the IE rendering engine in the platform SDK.
Whether IE is good or not is hardly relevant to the post as such, the good news however is that PNG support is complete in IE7, as well as improved CSS (though no CSS3).
Feel free to read my original post substituting 'IE' with 'Trident' however, the point of the post is the same.
In the same way Konqueror could with the proper slightly-malicious code injected hose KDE fairly well (run off and allocate KParts modules like mad or so), but normally wont.
Microsofts code no doubt has issues here and there, but it is not really a fundamental error on Microsofts part that causes a lot of spyware to wreck things once it gets on the system (whether microsoft is to blame for the spyware getting there to start with is a different matter though).
I don't think anyone can actually suggest that Microsoft throw it out, having a good rendering engine of type in the platform SDK is pretty much a requirement these days. The OSS desktops all leveraging HTML engines is just one example, check out Apple who are relly going at it building applications based on WebCore. It just so happens that Microsoft got into the game early (one could in fact use the word "innovation" here, but I guess that would be a bit too flamebaity on Slashdot).
Graduate student projects can often be fairly interesting and impressive, but you very deeply underestimate the work involved here. To put it this way; Academic projects are often very clever in a fundamental way, but commercial designs have year after year of very clever work done on every detail. This is not interesting to academia since it proves nothing about the design as such, it just creates a good end product.
I do recognize this myself though, I am often of a similar opinion about great pieces of software (I am firmly on the software side of things actually, though I have written some VHDL and have a general interest in computer architecture). It is easy to look at the fundamentals and say "the basic workings of this is trivial", but the devil is always in the details.
But, anyway, this story has long since dissappeared from the frontpage, lets get on with out lives.
I don't get the reference to Hennesy and Patterson at all here, while they do indeed discuss the implementation of pipelined chips with the Mips as the running example they do it on a high level. Doing an efficient implementation of even only the parts discussed in the book requires doing the actual clever implementation work of large portions of logic not really touched upon. Even things that are discussed are in so general terms that the books worth as a practical guide to actually building a modern chip is fairly low (it is an introductionary book after all). In addition they don't even discuss the issues involved in a chip of this level, notable missing parts are OoO logic and the FPU and so on (again understandable since it is an introduction).
Don't compare the R10000 to the stuff that a CS class hobbles together (which also tends to be a very small portion of a complete chip), it is an insult to all of computer architecture if anything.
So, the R10000 was very much state of the art in 1995, and is still doing fairly well today (the R160000 is pretty much the same core, just shrunk and tuned). If China has made an equivalent it is proof enough that they can make a competitive chip.
Google Groups non-usenet functionality is quite a bit younger than Yahoo Groups though (quite old community solution really). Also Google Groups features a quite confusing interface ever since the remake (and the remake was what added the non-usenet groups).
Sadly enough it is not at all suprising that Slashdot immediately goes for the anti-Windows slant rather than actually reading and comprehending the article and exploit in question. Too few actual axploits in Windows as of late to get up to the required quota perhaps?
In a more direct comment about the "exploit" I don't consider it terribly important, hardware access leads to a lot of trivial expoits. This one can be made more user-friendly than most with appropriate hardware, but it is not really worse than just inserting a boot CD that copies the relevant data to a secure server or so. It can also of course easily be fixed by disallowing loading of USB drivers without confirmation from the user.
I think you meant to say ALGOL. Few technological innovations have managed to simultaneously be so incredibly influential and obscure, not even Smalltalk really gets close. The quick summary is this; Algol is the language that inspired newer variations like C and Pascal.
The new hand-written recursive descent parser added in 3.4 improved performance a fair bit (making 3.4 the fastest g++ version ever as of the release they claim). The performance for compiling without optimization was improved even more in 4.0. For Gentoo users and other OCD-level recompilers it might not matter, but it does help developers everywhere. This is what I would personally call the place where it matters, end users that obsess over recompiling stuff themselves for no reason can wait.
It is overall a general consensus among gcc developers that performance should be improved. Don't expect C-level compilation speeds from C++ though, it is a heavy language to compile by nature. This keeps getting worse with the increasing prevalence of extreme template metaprogramming libraries like Boost, to a great part in meaningless areas in a quest for performance that will never matter or materialize (I don't claim that Boost or template metaprogramming is a bad thing, just that people obsessivly use it in places where normal coding practices would do just as well except for imagined performance/purity issues).
In retrospect my message is a bit whiny, it is a real security concern, it is just that I have read one too many slightly slanted reports on Microsoft security on Slashdot the last few years. Microsoft does a lot better today than they did before their security push and I am very happy to see this. Even for people who hate Windows it has to be heartening to see it improve, at least considering that there are no signs of Microsoft going away any time soon.
In an advisory posted at SecurityProtocols.com, the researcher described the issue as a remote kernel denial-of-service flaw affecting XP SP2, with the default firewall turned on.
I know Slashdot loves to hold Microsoft to golden standards, but a DOS-attack in a not overly important desktop daemon is hardly huge news. At the very least it happens to a lot of OS's a lot of the time.
Don't pretend that this is the most important thing in the world. It isn't, and people rightly don't take much interest in it.
It is if one includes the vector performance that the P4 looks good, the x87 is more or less just thrown in for compatibility expecting applications to move to the SSE2/SSE3 units instead. And those are fast.
The Pentium 4 has gotten a bad reputation, to some part well-deserved since it did not work out the way Intel had hoped in many ways. In the way of innovation and willingness to push the envelope Intel really did a great job with the Pentium 4 however. Really pushing for extreme frequency scaling (for example one should remember here that the P4 ALU's actually run at double the clockrate even), doing away with the aging x87 in favor of newer more streamlined SIMD instructions and overall doing one hell of a design job on it.
Things did not pan out as expected however, newer processes did not bring the frequency improvements Intel had hoped for (power leakage turned out to be larger than expected), and Intel really had expected it. Have a look at all the extreme-cooling experiments that successfully push the P4 to clockrates of well in excess of 4GHz (meaning that the CPU timings really are streamlined, it is a power leakage issue). Also the RAMBUS debacle messed things up for Intel, making the tradeoffs in the P4's memory hierarchy a lot worse than originally intended.
This is not intended as an apologetic post with regard to the P4, it did not live up to the promises the design tried to make. It is however still a mean performer in the right settings, and this includes opportunity to make it really output the FLOPS. It is a bit of a step down for people who liked the G5's ease of use, but for the Mac community it is mostly a step back to the way things was with the G4 (more work to get the performance, but the performance is there).
And what are scientific computation people doing on either the G5 or P4 at this point anyway? Off you go to the K8 already :)
Compare this to the G4, another weak linear performer that Apple more or less specialized in getting to fly through good use of the excellent Altivec unit. The G5 on the other hand has a somewhat weak Altivec unit but a much beefed up set of single-element FPU units, yielding so-so vector performing but good linear performance. IBM did probably not focus much energy on the Altivec unit but instead threw it in since Apple required it (after all, the single-element FPU performance of the G5 almost puts the Altivec unit to shame).
Some might now be quick to point out that Altivec is a nicer instruction set than SSE2/SSE3, this is by most standards true, but if you are hand-coding assembly you can make do with either. On the flip side Intel has quite impressive auto-vectorization support in their compiler.
So, what does this add up to? The G5 is in a good place for beating the P4 on unoptimized unvectorized code, but the P4 really screams if things are tuned up a bit. Considering Apples history with Altivec I think we can safely assume that they won't be afraid of doing some hand-tuning to get good perfomance.
This all ends up looking quite favorable for the P4, I still don't think we will see a commercial Mac with a P4 derivative in it, but anyone who thinks the P4 is a weak performer has another thing coming. For a bit more on my opinion on the state of the x86 vs. PPC today see my earlier post in the "Apple Switch to Intel Not a Big Loss for IBM" story.
Perl is also very large and complex, but what people tend to remember is the very terse syntax. Python has an insane number of language features piled up on it (and there is no sign of it stopping), all of them with fairly clear syntax, but it still makes the language as a whole very large (and with size comes complexity).
The code remains fairly easy to read, but the amount of syntax and semantics you have to learn to have a complete grasp just continues to increase, all in all it introduces power by having many specialized features, rather than for example C++ which introduces power by having a few very powerful concepts (templates) which can achieve a lot of different goals (in very obscure ways).
Lets just have a look at the latest release, Python 2.4:
There are a lot more new in Python 2.4, but these are some of the more major changes. And this is with 2.3 having been released less than 1.5 years earlier. 2.4 is nothing special either, huge amounts of changes like these happen with every Python release. This lands us in some trouble, with tons of new syntax and semantics added to the core language in every release it is very hard to actually keep up or even worse, try to use different versions at the same time. It is also a very hard job for any newbie to get proficient with all the features of Python, meaning that one ends up having to spend a very long time before one can expect to understand other peoples code.This one can contrast with most other languages, where the core language is not changed more often than perhaps once or twice per decade. They instead try to offer more powerful basic constructs and expect users to build from there. The Python approach has its advantages, but it is hard to dispute that the end result can not really be considered elegant.
People like to take shots at the x86, but it is hard to deny that there are brilliant people working on it, really making implementations that fly. Intel's development team has a long proud history (they pretty much single-handedly turned the perception of CISC/RISC around with the Pentium Pro after all), and the AMD K8 team looked suspiciously much like the Alpha team at one point.
That is not to say that the POWER4 and derivatives are not impressive, they are, but the performance of chips like the AMD K8 really proves that if you have a competent team small details like the ISA don't matter all that much. I see no easy way for IBM to sneak into China, and it is actually a good thing; We are all better off with:
By comparison the PPC would be a fairly serious case of lock-in, only two companies manufacture chips (Freescale/Motorola and IBM), and Freescale mostly bothers with embedded applications.In summary, having some PPC around is nice, but having it take over a market would be a bad thing at this point.
C# and Java are both clearly more elegant designs, as is C really. C++ has a lot of syntax, and rather wacky semantics in parts, but it manages a lot of power with a few very important concepts (templates). Overall, in elegance I would probably rate Python second to last of the languages listed (VB is extremely unelegant). This does not mean that it is a bad language (though I personally don't care for it), it is powerful and featureful, but it pays for it by being a huge language.
I don't see any problem at all with this if it is indeed for all non-intel processors. Targeting a competitor directly by slowing things down is a bad thing, but putting in the simplest default fallback for any other processors than the one you are trying to optimize for seems like a very reasonable way to go. To put it this way; Intel makes a compiler optimized for their products, and they throw in a simple fallback to supply simple code that should work on any basic x86 compatible. If it can be demonstrated that the intent of this is to damage AMD it is a bad thing, but it seems more likely that Intel simply does not care about the performance of the compiler on any other implementation (and seeing how they by no means have a monopoly on compilers there is nothing wrong with that).