I would beg to differ. CPUs have been showing a reverse trend... leaving aggressive hardware based optimizations to cram in more cores and increase the performance/watt. This generally helps increase throughput but slows single threaded performance. Thankfully, desktop processors are still not going the same direction where single threaded application performance still matters.
CPUs are not about to evolve more. You might say systems will evolve more... the interconnects, more cores, more SIMD, NUMA etc. Your examaples actually show problems in algorithms used... not the hardware on which it runs.
Compilers cannot make up for multi-core CPU fiasco IMHO. A multicore CPU exposes an abstraction of separate processors which the OS (generally) uses to do SMP. Once at this level, besides doing openmp like vectorization using threads the compiler actually doesn't do anything else. Compilers will OTOH play a significant role for VLIW architectures like the Itanium.
JIT is another form of compilation. Its however "fast" compilation with an eye towards optimization and targets only performance centric areas in the running program. The biggest advantage of a JIT against a compiler is that it uses run time profile information to optimize the code. Something which gprof and gcc would do but I am sure nobody bothers. A JIT based compilation technique is bound to succeed in the future for the following reasons:
1) Multicores can do compilation and execution of the program on separate cores. 2) For most desktop application work, there is a good room for optimization based on profile data. Oh course this is only my hunch:)
Another important factor is garbage collection. The primarily used compiled languages today (C/C++) don't have garbage collection (talking about non-conservative gc). Most recent languages have seen the benefits of garbage collection and have adopted it besides also adopting JIT. This alone can lead JIT into the mainstream.
Slashdot Mirror
I would beg to differ. CPUs have been showing a reverse trend... leaving aggressive hardware based optimizations to cram in more cores and increase the performance/watt. This generally helps increase throughput but slows single threaded performance. Thankfully, desktop processors are still not going the same direction where single threaded application performance still matters.
CPUs are not about to evolve more. You might say systems will evolve more... the interconnects, more cores, more SIMD, NUMA etc. Your examaples actually show problems in algorithms used... not the hardware on which it runs.
Compilers cannot make up for multi-core CPU fiasco IMHO. A multicore CPU exposes an abstraction of separate processors which the OS (generally) uses to do SMP. Once at this level, besides doing openmp like vectorization using threads the compiler actually doesn't do anything else. Compilers will OTOH play a significant role for VLIW architectures like the Itanium.
:)
JIT is another form of compilation. Its however "fast" compilation with an eye towards optimization and targets only performance centric areas in the running program. The biggest advantage of a JIT against a compiler is that it uses run time profile information to optimize the code. Something which gprof and gcc would do but I am sure nobody bothers. A JIT based compilation technique is bound to succeed in the future for the following reasons:
1) Multicores can do compilation and execution of the program on separate cores.
2) For most desktop application work, there is a good room for optimization based on profile data. Oh course this is only my hunch
Another important factor is garbage collection. The primarily used compiled languages today (C/C++) don't have garbage collection (talking about non-conservative gc). Most recent languages have seen the benefits of garbage collection and have adopted it besides also adopting JIT. This alone can lead JIT into the mainstream.