NET compilación o complicación?

Question

Q1) ¿Por qué es C # inicialmente compilado a IL y después en tiempo de ejecución JIT cumplió y se ejecutan en la parte superior de una máquina virtual (?). ¿O es que JIT cumplió a código máquina nativo?

Q2) Si la segunda es verdadera (JIT cumplió en código máquina nativo), entonces ¿dónde está la caja de arena .NET el código se ejecuta bajo?

Q3) Además, ¿por qué es el código compilado para IL en el primer lugar. ¿Por qué no simplemente compilar a código nativo de la máquina todo el tiempo? Hay una herramienta de MS de esta llamada NGEN pero ¿por qué es que optativo?

Answer 1

La IL es JIT'd (JIT = Just In Time) compilado al código de máquina nativo como el proceso se ejecuta.

El uso de una capa de máquina virtual permite .NET se comporte de una manera consistente en todas las plataformas (por ejemplo, un int es siempre 32 bits, independientemente de si se está ejecutando en una máquina de 32 o de 64 bits, esto no es el caso con C ++).

compilación JIT permite optimizaciones para adaptar dinámicamente a sí mismos al código, ya que corre (por ejemplo, aplicar optimizaciones más agresivas para bits de código que se suelen llamar, o hacer uso de instrucciones de hardware disponible en la máquina específica como SSE2), que se puede' t hacer con un compilador estático.

Answer 2

A1) JIT compila a código máquina nativo

A2) En .NET no existe un término tal como caja de arena. Hay dominios de aplicación en su lugar. Y se ejecuta como parte de CLR (es decir, como parte del proceso ejecutable)

inconvenientes A3) NGEN de Jeffrey Richter:

archivos

• NGen'd pueden perder la sincronización. Cuando el CLR carga un archivo NGen'd, se compara una número de características sobre el código previamente compilado y la ejecución actual ambiente. Si alguna de las características no coinciden, el archivo no puede ser NGen'd utilizado, y el proceso JIT compilador normal se utiliza en su lugar.

• Inferior rendimiento en tiempo de carga (Rebase / Encuadernación). archivos de ensamblaje son archivos estándar de Windows PE, y, como tal, cada uno contiene una dirección base preferida. Muchas ventanas los desarrolladores están familiarizados con los temas relacionados con direcciones de base y cambio de base. Cuando JIT compilar el código, estos problemas no son una preocupación porque las referencias a direcciones de memoria correcta se calculan en tiempo de ejecución.

• Inferior rendimiento en tiempo de ejecución. Al compilar el código, NGen no puede hacer tantas supuestos sobre el entorno de ejecución como lo hace el compilador JIT. Esto causa Ngen.exe para producir código inferior. Por ejemplo, NGen no va a optimizar el uso de ciertas instrucciones de la CPU; se añade indirecciones de acceso campo estático debido a que el real dirección de los campos estáticos no se conoce hasta tiempo de ejecución. NGen inserta código para llamar a la clase constructores de todo el mundo, ya que no conoce el orden en que el código se ejecutará y si un constructor de la clase ya se ha llamado.

Answer 3

Puede utilizar NGEN para crear versiones nativas de sus ensamblados .NET. Hacer esto significa que el JIT no tiene que hacer esto en tiempo de ejecución.

.NET se compila a IL primero y luego a nativo ya que el JIT fue diseñado para optimizar el código IL para la CPU actual el código se ejecuta bajo.

.NET código se compila a IL para compatibilidad. Ya que se puede crear un código en C #, VB.NET, etc, entonces el JIT necesita un conjunto de instrucciones comunes (IL) con el fin de compilar a código nativo. Si el JIT tenía que ser conscientes de las lenguas, entonces necesitaría el JIT que actualizarse cuando un nuevo lenguaje .NET fue puesto en libertad.

No estoy seguro acerca de la cuestión caja de arena, mi mejor conjetura es que una aplicación .NET funciona con 3 dominios de aplicación. Un dominio contiene los tiempos de ejecución de .NET (mscorlib, System.dll, etc), otro dominio contiene el código de .NET, y no puedo recordar lo que el dominio del otro para. Echa un vistazo a http://my.safaribooksonline.com/9780321584090

Answer 4

1. C # es compilado a CIL (o IL), ya que comparte plataforma con el resto de los lenguajes .NET (por lo que se puede escribir un archivo DLL en C # y utilizarlo en VB.NET o C # sin problemas). El CLR entonces JIT compilar el código en código máquina nativo.

.NET también se puede ejecutar en múltiples plataformas (Mono * NIX y OS X). Si C # compilado a código nativo, esto no sería tan fácil.

2. No hay caja de arena.

3. cubierto en la respuesta a # 1

Answer 5

A1) De esta manera es independiente de la plataforma (Windows, Linux, Mac) y también puede utilizar optimizaciones específicas para el hardware actual. Cuando se compila JIT es a código máquina.

A2) Todo el marco (NET Framework) es todo lo que arenero todas las llamadas que puede hacer a través de su aplicación va a ir a través de la caja de arena marco .NET.

A3) Como en respuesta 1, permite que el binario .NET para trabajar en diferentes plataformas y realizar optimizaciones específicas en la máquina cliente sobre la marcha.

Answer 6

código .Net Compilado convierte IL que es un lenguaje intermedio de la misma manera exacta que la de código objeto Javas'. Sí, es posible generar un código máquina nativo usando el href="http://msdn.microsoft.com/en-us/library/6t9t5wcf.aspx" rel="nofollow noreferrer"> NGen herramienta

Además, NGen es opcional, ya que como he dicho, se une el binario al sistema, que puede ser útil cuando se necesita el rendimiento del código máquina compilado con la flexibilidad de un lenguaje de tipos dinámicos y usted sabe que el binario no lo hará puede pasar a un sistema que no está obligado a.