>Your statement is technically incorrect.
>
>The CLR is not a runtime interpreter. Instead, the CLR performs JIT compilations on the code before it is executed. In other words: The IL code is compiled before it runs into something that is very similar to native code, except that it does not have to do things like memory management.

....and I thought VFP apps were easy to decompile...geeze.



>The fact that memory management is one way for .NET code to run faster than regular unmanaged code. The other aspect is that JIT compilation is highly optimized for the machine it is compiled on. Technically, you are correct. One can write unmanaged code that is just as optimized for a certain machine. Practically, this is not possible, since you would have to ship thousands of different EXEs (for all the different configurations), and even then you would not get close. (One slight change in a system's configuration could require different optimizations).
>
>Also, some people seem to think that the CLR will one day run in silicone. In other words: People are apparently working on processors that can natively run IL. Kinda like a "IL accelerator". Not sure where that is at, but it is def. being talked about. On such chips, native code would have to be emulated.
>
>Markus
>
>
>>Hi Dorin,
>>
>>>I've readed in a lot of places that .NET managed code can run even faster and more efficient than native code (with benchmarks proving this
>>
>>This is technically impossible. .NET itself is coded natively and its CLR is a runtime intepretator that runs native code internally. While the CLR is very efficient in running the CLR instructions, it still has to run native code (your CPU does only understand native code). So if for some algorithm you program a .NET piece of code, it might come close to a native solution, but never can beat native code, because the CLR has to translate the .NET instuctions into a native code solution.
>>
>>What I suspect they are trying to say, is that it is possible to create an algorithm in a short time that runs very efficient native code whereas if you try to program the same algorithm in native code you might end up with a less efficient solution, because if you want to make it more efficient you´d have to program a lot more code.
>>
>>The same you could say about VFP in relation to .NET. See the programming challenge in which calvin hsia has participated: you can use VFP cursor as a way to store and search for words in a simular way as using binary trees in C/C++/.NET. However, implementing a dynamic b-tree storing mechansim requires a lot of programming (with the risk of bugs,etc) while it is natively available in VFP. So using indexed cursor in VFP only requires a few lines, while using such functionality in other languages requires you have at the least to link other libraries, or program it yourself.
>>
>>IMO, this is the area where VFP excells. Having very powerfull functions and mechnisms to adress common problems very quickly an efficient.
>>
>>Walter,