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?
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.