Why C# native is faster than C# CLR-bytecode? The fact is that CLR JIT compiler must generate native code for a superscalar processor, but CLR is a stack machine. What about the conversion from stack machine to RISC-CISC machine? This issue is also a research topic for Java compilation, because JVM and CLR are stack machines.
C# JIT compiler generate code for take advantage of Instruction Level Parallelism of modern processors?
What about a SPEC benchmark for C#?
I know exists this benchmarks for Java, but I think C# compiler researchers need this benchmarks in order to test their optimizations.
Is the superscalar processor the best platform for execute .NET? (considering that .NET CLR is a stack machine and a superscalar processor is a machine based in registers)
Do you remember the idea of Java processors (Sun's specification named "picoJava")?
Why not a .NET hardware processor, where native code is the same bytecode?
What thinks Microsoft about this idea?
Imagine Azure datacenters with big Symmetric Multiprocessor servers with hundred of .NET processors.
@carlospinedag:obviously there are no mass deployment of picoJava around. why would the idea work with .NET this time? What do you think is different nowadays that will make it work?