Ratbert, <Everyone talks about that CPU's in general are faster than most people need. But there is a very important trend that will counteract this: That software developers will use tools and languages which result in faster development, but slower running.>
You make a good point here, but I think the two examples you used to support your point, Java and Transmeta, aren't the best choices. Transmeta, in particular, is heavily reliant on software in order to emulate the x86 architecture and implement the power-conservation features of their Crusoe processor. And Java's performance is very dependent on optimizing the JVM for a particular architecture. Even with an optimized JVM, the performance of Java is still terrible. (And the cross-platform issues still haven't been resolved yet, even years after the Java hype reached its peak.)
In both of those examples, performance is much more dependent on software than any of Intel's latest projects (with IA-64 being an exception, of course). I don't think it's fair to say that Intel is making a fundamental mistake, when it's apparent that the competition will also have to rely on software to improve hardware performance. Even AMD's upcoming Sledgehammer will need specific software enhancements, most notably for its 64-bit extensions and RISC-like FPU, in order to fully realize its performance potential. (And even after that, it's probably not going to measure up to the 32-bit performance of Willamette or the 64-bit performance of McKinley.)
Tenchusatsu |
