.NET Código Compilação ou Complicação?

Question

Q1) Por que o C# é inicialmente compilado ao IL e, em tempo de execução, o JIT cumpriu e é executado no topo de uma máquina virtual (?). Ou é que o JIT cumpriu o código da máquina nativo?

Q2) Se o segundo é verdadeiro (o JIT cumpriu o código da máquina nativo), onde está o .NET Sandbox em que o código é executado?

Q3) Além disso, por que o código é compilado ao IL em primeiro lugar. Por que não simplesmente compilar com o código da máquina nativo o tempo todo? Existe uma ferramenta do MS deste chamada NGEN, mas por que isso é opcional?

Answer 1

O IL é Jit'd (JIT = Just in Time) compilado ao código da máquina nativo à medida que o processo é executado.

O uso de uma camada de máquina virtual permite que o .NET se comporte de maneira consistente entre as plataformas (por exemplo, um int é sempre 32 bits, independentemente de você estar em uma máquina de 32 ou 64 bits, esse não é o caso do C ++ ).

A compilação do JIT permite que otimizações se adaptem dinamicamente ao código à medida que ele é executado (por exemplo, aplique otimizações mais agressivas a bits de código que são chamados com frequência ou utilizam instruções de hardware disponíveis na máquina específica como o SSE2), com o qual você não pode fazer com um compilador estático.

Answer 2

A1) JIT compila com código de máquina nativo

A2) No .NET, não existe um período como Sandbox. Há appdomains. E eles são executados como parte do CLR (ou seja, como parte do processo executável)

A3) NGEN DAVERSABES DE JEFFREY RICHTER:

• Os arquivos ngen'd podem sair da sincronização. Quando o CLR carrega um arquivo ngen'd, ele compara várias características sobre o código compilado anteriormente e o ambiente de execução atual. Se alguma das características não corresponder, o arquivo ngen'd não poderá ser usado e o processo normal do compilador JIT será usado.

• Desempenho de tempo de carga inferior (Rebasing/Binding). Os arquivos de montagem são arquivos PE Windows padrão e, como tal, cada um contém um endereço base preferido. Muitos desenvolvedores do Windows estão familiarizados com os problemas em torno de endereços básicos e rebateding. Quando o código de compilação do JIT, esses problemas não são uma preocupação porque o endereço de memória correto referências são calculadas no tempo de execução.

• Desempenho inferior no tempo de execução. Ao compilar o código, o NGen não pode fazer tantas suposições sobre o ambiente de execução quanto o compilador JIT pode. Isso faz com que o ngen.exe produza código inferior. Por exemplo, o NGEN não otimizará o uso de determinadas instruções da CPU; Ele adiciona indiramentos para o acesso de campo estático porque o endereço real dos campos estáticos não é conhecido até o tempo de execução. O ngen insere código para ligar para construtores de classe em todos os lugares, porque não conhece a ordem em que o código será executado e se um construtor de classe já foi chamado.

Answer 3

Você pode usar Ngen Para criar versões nativas dos seus conjuntos .NET. Fazer isso significa que o JIT não precisa fazer isso em tempo de execução.

O .NET é compilado para IL primeiro e depois para o nativo, pois o JIT foi projetado para otimizar o código IL para a CPU atual em que o código está em execução.

O código .NET é compilado para IL para compatibilidade. Como você pode criar código usando C#, vb.net, etc, o JIT precisa de um conjunto de instruções comuns (IL) para compilar com o código nativo. Se o JIT tivesse que estar ciente dos idiomas, o JIT precisaria ser atualizado quando um novo idioma .NET foi lançado.

Não tenho certeza sobre a pergunta do Sandbox, meu melhor palpite é que um aplicativo .NET é executado com 3 domínios de aplicativos. Um domínio contém o .NET RunTimes (mscorlib, system.dll, etc), outro domínio contém seu código .NET, e não consigo me lembrar do que é o outro domínio. Verificação de saída http://my.safaribooksonline.com/9780321584090

Answer 4

1. C# é compilado no CIL (ou IL) porque compartilha uma plataforma com o restante dos idiomas .NET (e é por isso que você pode escrever uma DLL em C# e usá -lo em vb.net ou f# sem problemas). o Clr Em seguida, irá compilar o código no código da máquina nativo.

O .NET também pode ser executado em várias plataformas (mono no *nix e OS X). Se C# compilado com código nativo, isso não seria tão fácil.

2. Não há caixa de areia.

3. Coberto na resposta para #1

Answer 5

A1) Dessa forma, é a plataforma agnóstica (Windows, Linux, Mac) e também pode usar otimizações específicas para o seu hardware atual. Quando é compilado JIT, é para o código da máquina.

A2) Toda a estrutura (a estrutura .NET) é toda a caixa de areia; portanto, todas as chamadas que você pode fazer através do seu aplicativo passará pela caixa de areia .NET Framework.

A3) Como na resposta 1, permite que o binário .NET funcione em diferentes plataformas e execute otimizações específicas na máquina cliente em tempo real.

Answer 6

O código .NET compilado se torna IL, que é uma linguagem intermediária exatamente da mesma maneira que a do código do objeto de Java. Sim, é possível gerar código de máquina nativo usando o Ngen ferramenta. O nGen liga a imagem nativa resultante à máquina; portanto, copiar o binário ngen'd para um sistema diferente não produziria resultados esperados. Compilar ao código intermediário permite decisões de tempo de execução que podem ser tomadas que, de outra forma, não podem (facilmente) ser tomadas com um idioma de tipo estáticamente tipado, como C ++, também permite o funcionamento do código em diferentes arqueturas de hardware, porque o código se torna descritivo no Sentir que ele também descreve a intenção do que deve acontecer em uma maneira agnóstico (por exemplo, 32 ou 64), em oposição ao código específico da máquina que funciona apenas em sistemas de 32 bits ou sistemas de 64 bits, mas não ambos.

Além disso, o NGEN é opcional porque, como eu disse, liga o binário ao sistema, pode ser útil quando você precisa do desempenho do código da máquina compilado com a flexibilidade de um idioma tipado dinamicamente e você sabe que o binário não se moverá para um sistema para o qual não está vinculado.