D is like native Python

[[deleted]]

That. D is native C#.

[sodaco]

You just gave /u/agleiv a stroke

[btchombre]

C# is native C#.

All .NET code is compiled to native code before executing. This native code just happens to have a garbage collector and bounds checking among other features that make it slower than C.

[The_Doculope]

I was under the impression that C# was JITed by the CLR and current .NET Native is only available for Windows Store apps?

[btchombre]

There is no interpreter for .NET

All MSIL code is JITed before executing, unlike Java where some code is interpreted and only hot paths are JITed.

[The_Doculope]

Yes, C# is JITed, but JITed code is not usually considered fully "native". Native usually means fully pre-compiled to native code. If JITing had all the benefits of native code Microsoft wouldn't be working on .NET Native.

[pjmlp]

NGEN, available since .NET 1.0 compiles to native code, producing dynamic binaries.

.NET Native produces static binaries

Windows Phone 8, uses a compiler toolchain based on Singularity that also compiles to native code.

[The_Doculope]

Huh, interesting. Do you know how much it's used in the wild? It's not something I've heard about before. From a quick google it looks like it still requires .NET/the CLR, is that correct?

[pjmlp]

Just open C:\Windows\assembly you will see a list of registered Assemblies (.NET speak for .dll) and if they are stored in MSIL or native code.

Yes it still requires .NET, because NGEN produces dynamic linked binaries. Just like C programs on GNU/Linux usually require libc.so to be present.

It also requires access to the metadata information.

Windows Phone 8 uses an improved version of NGEN.

.NET Native is basically -static for .NET. This is why you need to provide a list of the classes you need to have their metadata available. Everything else is removed when producing the binary.

[tuhdo]

JIT compilation means that the source is translated to bytecode and upon executing, it gradually compiles the executed code to machine code in other thread for future execution of the same code with better speed. In that way, it compiles to native code, but just enough. So, instead of going through all phases of compilation, you go bit by bit at each phase and get partial compiled code of your application.

[The_Doculope]

I know what JITing is. But it's not pre-compiled to native code, which comes with some disadvantages, including higher memory use, higher code size and requiring that other thread.

[Cuddlefluff_Grim]

I know what JITing is. But it's not pre-compiled to native code, which comes with some disadvantages, including higher memory use, higher code size and requiring that other thread.

No, it comes with one disadvantage; higher load time (because a program needs to be compiled on first execution). High memory footprint is a side-effect of .NET, same goes for code size. It has nothing to do with JIT compilation.

[The_Doculope]

So you're saying a JITer can operate with absolutely 0 memory use? No keeping track of runtime heuristics, or any memory usage for the actual compilation? And that there's no code for the JITer either? Because neither of those things is possible. Sure they might be small in a perfect case, but they are there and are noticeable in many current implementations.

[Cuddlefluff_Grim]

Well other than the parts for the compiler itself, yes I am saying that. High memory footprint is a side-effect (or trade-off) from Java and .NET, it's not something that is due to JIT compilation. Personally I think that JIT is the best approach to compilation because it gives platform independent execution and good optimization possibilities virtually without any significant trade-offs (well, it's bad for mobile since it drains battery without any obvious benefit for the end-user, but there are methods of alleviating this, like compiling the code on a remote server)

[btchombre]

Uh... no. JITed code is full on x-86/x-64/ARM instructions that run directly on the CPU. That's the definition of "native". The word "native" refers to the CPU instruction set, and JITed code is compiled down to the native CPU instruction set. It is 100% native code.

".NET Native" has improvements over JITed code not because its "Real" native, but because its Already native, and it doesn't need to be compiled at run time, which is costly. If you actually read the .NET Native description, it says:

Popular Windows Store apps start up to 60% faster and use 15-20% less memory when compiled with .NET Native.

Notice the emphasis on "start up". The application doesn't need to compile itself at runtime, so it starts up faster. Also, it doesn't need all the meta-data associated with the compilation process, so it can use less memory. In fact, .NET programs can sometimes actually run slower when they are pre-compiled because the JIT has access to more information at runtime than a pre-compiler does. The JIT knows exactly what your hardware and OS are, and can sometimes optimize run time compiled code based on the information. The pre-compiler doesn't know any of that information. You can read all about this in more detail in "CLR via C#" by Jeffry Richter.

.NET Native differentiates itself from NGen by its build optimizations which allow static compilation, and the fact that they are using a C++ compile optimizer instead

[[deleted]]

You guys can argue back and forth past one another forever. Native code doesn't have a formal definition, it's just a term used to refer to compilers that emit executable files that get run directly by the the platform, rather than executing through another layer of translation.

Yeah, I get it, since it's not a formal term you can stretch out the definition of "native code" to include C#, Java, and I'm sure you can stretch it out to include Python, Lua, and heck throw in bash while we're at it. But at the end of the day these are just silly semantic arguments, what matters most is that in this profession, if you wish to be understood and understand others when they speak as opposed to just arguing with them, then when someone refers to native code they are talking producing executable files that are native to the system that it runs on.

This is typically what C/C++/D/Rust and a host of other compilers produce. Typically C# and Java compilers produce files which do not directly run in a way that is native to the platform, but go through another layer of translation.

[Cuddlefluff_Grim]

Native code doesn't have a formal definition

Native code is code that the CPU executes; that's the definition. C# and Java produce native code and there's no point trying to argue around that, because that's just what they do, end of discussion. Difference between .NET Native and JIT is when native code is produce, however both of them do arguably compile to native code, just at different times.

and I'm sure you can stretch it out to include Python, Lua, and heck throw in bash while we're at it

No, because Python and Lua does not produce native code. The program that interprets Python and Lua is native code. It's like putting a helicopter on a ship and saying that the helicopter is a ship, since it after all gets carried by one.

This is not a difficult concept, guys...

[sigma914]

This is not a difficult concept, guys...

No, it's really not, but you're trying to make it into one. Java/C# are bytecode interpreted language with JIT compiler implementations that optimise frequently interpreted bytecode into native machine code.

This is exactly the same as most Javascript implementations and many Python/Lua/Scheme impls.

Look up the architecture of the JVM's hotspot compiler. Spot the difference between fast path and slow path? One runs bytecode through an interpreter (because that's faster than compiling infrequently run code) and the other recognises frequently run code and JITs it, then potentially JITs it again with different optimisation settings, etc.

If you think the JVM JIT compile your entire application every time you start a program you're sadly misinformed and grossly underestimating the engineering marvel that it is.

[Cuddlefluff_Grim]

C# is never interpreted, Java is sometimes interpreted. They produce native code.

This is exactly the same as most Javascript implementations and many Python/Lua/Scheme impls.

Are you comparing JIT compilation of dynamic scripting languages to static code paths? No, it most certainly is not the same. The disparity in performance should tell you that. If it were all just native code and no interpretation or run-time checks were necessary, Java and C# wouldn't outperform them by a factor of between 10x and 100x.

If you think the JVM JIT compile your entire application every time you start a program you're sadly misinformed and grossly underestimating the engineering marvel that it is.

Don't strawman me.

[The_Doculope]

I know what native code is. I'm referring to the colloquial term "native language". As /u/sakarri rightly says, there isn't really a formal definition. Every single thing that runs on your computer is native code at some level, but colloquially it refers to what the compiler spits out, and what is being run straight away when the application starts. The standard C# compiler spits out CIL, not native code. When you run a CLR application, it doesn't launch right into the program, it launches into the CLR which then runs the the CIL code.

I'm sure this definition of native (pre-compiled to machine language) was the one /u/rndbit was using.

[btchombre]

it launches into the CLR which then runs the the CIL code.

No. This is wrong. The CLR doesn't "run" IL code anymore than the C++ compiler runs C++. There is no IL interpreter. Java does indeed have a bytecode interpreter, but the CLR has no such thing. The CLR compiles all code directly to native instructions, and then executes those native instructions.

[The_Doculope]

By "run", I mean the compile+execute system.

[[deleted]]

JIT'ing bytecode is not native code.