Qual é a relação entre intérpretes meta-circulares, máquinas virtuais e desempenho aprimorado?


12

Eu li sobre intérpretes meta-circulares na web (incluindo o SICP) e examinei o código de algumas implementações (como PyPy e Narcissus).

Eu li bastante sobre duas línguas que fizeram um ótimo uso da avaliação metacircular, Lisp e Smalltalk. Até onde eu entendi, o Lisp foi o primeiro compilador de hospedagem automática e o Smalltalk teve a primeira implementação "verdadeira" do JIT.

Uma coisa que não entendi completamente é como esses intérpretes / compiladores podem alcançar um desempenho tão bom ou, em outras palavras, por que o PyPy é mais rápido que o CPython? É por causa da reflexão?

E também, minha pesquisa no Smalltalk me levou a acreditar que há uma relação entre JIT, máquinas virtuais e reflexão. Máquinas virtuais como a JVM e o CLR permitem uma grande introspecção de tipos e acredito que elas fazem grande uso na compilação Just-in-Time (e AOT, suponho?). Mas, tanto quanto eu sei, as Máquinas Virtuais são como CPUs, pois possuem um conjunto de instruções básicas. As Máquinas Virtuais são eficientes porque incluem informações de tipo e referência, o que permitiria uma reflexão independente do idioma?

Eu pergunto isso porque muitas linguagens interpretadas e compiladas agora estão usando bytecode como destino (LLVM, Parrot, YARV, CPython) e VMs tradicionais como JVM e CLR obtiveram melhorias incríveis no desempenho. Foi-me dito que é sobre o JIT, mas, tanto quanto eu sei, o JIT não é novidade desde que o Smalltalk e o próprio Self da Sun o fizeram antes do Java. Não me lembro de VMs com desempenho particularmente bom no passado, não havia muitas não-acadêmicas fora da JVM e .NET e seu desempenho definitivamente não era tão bom quanto é agora (eu gostaria de poder obter essa reivindicação, mas eu falar por experiência pessoal).

De repente, no final dos anos 2000, algo mudou e muitas VMs começaram a aparecer mesmo em idiomas estabelecidos e com desempenho muito bom. Foi descoberto algo sobre a implementação do JIT que permitiu que praticamente todas as VMs modernas disparassem no desempenho? Um papel ou um livro, talvez?


3
Dinheiro. O dinheiro que é utilizado para ser vertida em C ++ e Fortran agora é vertida para o ponto quente, CLR, mono, V8, nitro, SpiderMonkey, etc
Jörg W Mittag

Eu posso apenas imaginar, mas eu acho que é apenas a melhoria ao longo do tempo, como descrito aqui joelonsoftware.com/articles/fog0000000017.html
Doc Brown


1
@ Gomi Não se trata de quão semelhante a linguagem de implementação é à linguagem implementada. Existem intérpretes JavaScript, Lisp, Prolog, SmallTalk e Ruby escritos em RPython e eles recebem exatamente as mesmas vantagens que o PyPy oferece. A única razão pela qual o RPython é baseado no Python é que ele foi criado por vários entusiastas do Python. Os recursos do RPython que tornam o PyPy rápido não têm nada a ver com o Python: geração automática de compilador JIT, coletores de lixo etc. - e sim, a maior parte disso poderia, em princípio, ser feito usando outras linguagens. Você teria que criar um compilador totalmente novo.

4
-1 porque você parece ter pelo menos três perguntas diferentes aqui: (a) Por que as implementações meta-circulares são tão boas? (b) As VMs são eficientes devido às informações de tipo e a introspecção é benéfica para o desempenho? (c) Como a popularidade da VM aumentou no final dos anos 2000 e como, de repente, elas tiveram um bom desempenho? Eu acho que é melhor fazer essas perguntas separadamente.
Oak

Respostas:


1

2 de 3: Não há relação entre os tempos de execução da linguagem "meta-circular" e "alto desempenho". Os tempos de execução meta-circulares que atingem alto desempenho fazem isso compilando JIT com o código nativo e executando o código nativo. Não há razão para que o tempo de execução do seu hi-perf Python precise ser escrito em Python ou Lisp em Lisp, etc. Mas se você acha que sua linguagem é mais poderosa, expressiva etc. do que as outras, por que não usá-la seu próprio tempo de execução? Ou se você não acha que seu idioma é de alguma forma "melhor" que os outros, por que você está se dando ao trabalho de implementá-lo?

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.