Quais recursos semânticos do Python (e de outras linguagens dinâmicas) contribuem para sua lentidão?
Nenhum.
O desempenho das implementações de idiomas é uma função do dinheiro, recursos e teses de doutorado, não dos recursos de idiomas. Self é muito mais dinâmico que Smalltalk e um pouco mais dinâmico que Python, Ruby, ECMAScript ou Lua, e tinha uma VM que superava todas as VMs Lisp e Smalltalk existentes (na verdade, a distribuição Self era fornecida com um pequeno interpretador Smalltalk escrito em Self , e até isso era mais rápido que a maioria das VMs Smalltalk existentes) e era competitivo com as implementações de C ++ da época.
Então, a Sun parou de financiar o Self e a IBM, Microsoft, Intel e Co. começaram a financiar C ++, e a tendência foi revertida. Os desenvolvedores do Self deixaram a Sun para abrir sua própria empresa, onde usaram a tecnologia desenvolvida para a Self VM para criar uma das VMs Smalltalk mais rápidas de todos os tempos (a VM Animórfica) e, em seguida, a Sun comprou de volta a empresa e uma versão ligeiramente modificada do essa VM Smalltalk agora é mais conhecida sob o nome de "HotSpot JVM". Ironicamente, os programadores Java desprezam as linguagens dinâmicas por serem "lentos", quando, na verdade, Javaficou lento até adotar a tecnologia de linguagem dinâmica. (Sim, isso mesmo: a JVM do HotSpot é essencialmente uma VM Smalltalk. O verificador de bytecode faz muita verificação de tipo, mas uma vez que o bytecode é aceito pelo verificador, a VM e, especialmente, o otimizador e o JIT, na verdade, não muito interesse com os tipos estáticos!)
O CPython simplesmente não faz muita coisa que torna as linguagens dinâmicas (ou melhor, o despacho dinâmico) rápido: compilação dinâmica (JIT), otimização dinâmica, inlining especulativo, otimização adaptativa, des otimização dinâmica, feedback / inferência do tipo dinâmico. Também existe o problema de que quase todo o núcleo e a biblioteca padrão são escritos em C, o que significa que, mesmo que você torne o Python 100x mais rápido de repente, isso não ajudará muito, porque algo como 95% do código executado por um O programa Python é C, não Python. Se tudo fosse escrito em Python, até mesmo acelerações moderadas criariam um efeito de avalanche, em que os algoritmos ficam mais rápidos e as estruturas de dados principais ficam mais rápidas, mas é claro que as estruturas de dados principais também são usadas nos algoritmos e nos algoritmos e dados principais. estruturas são usadas em qualquer outro lugar,
Existem algumas coisas notoriamente ruins para as linguagens OO gerenciadas por memória (dinâmicas ou não) nos sistemas atuais. A memória virtual e a proteção de memória podem ser determinantes para o desempenho da coleta de lixo em particular e o desempenho do sistema em geral. E é completamente desnecessário em um idioma seguro para a memória: por que proteger contra acessos ilegais à memória quando não há acesso à memória no idioma? A Azul decidiu usar MMUs poderosas e modernas (Intel Nehalem e mais recentes, e o equivalente da AMD) para ajudar na coleta de lixo em vez de impedi-la, mas mesmo sendo suportado pela CPU, os atuais subsistemas de memória dos sistemas operacionais convencionais não são poderosos o suficiente para permitir isso (e é por isso que a JVM da Azul realmente é virtualizada no bare metal, além de o SO, não dentro dele).
No projeto Singularity OS, a Microsoft mediu um impacto de ~ 30% no desempenho do sistema ao usar a proteção MMU em vez do sistema de tipos para separação de processos.
Outra coisa que a Azul notou ao criar suas CPUs Java especializadas foi que as CPUs mainstream modernas se concentram na coisa completamente errada ao tentar reduzir o custo de falhas de cache: elas tentam reduzir o número de falhas de cache através de coisas como previsão de ramificação, pré-busca de memória, e assim por diante. Mas, em um programa OO fortemente polimórfico, os padrões de acesso são basicamente pseudo-aleatórios, simplesmente não há nada a prever. Portanto, todos esses transistores são desperdiçados e o que se deve fazer é reduzir o custo de cada falta de cache individual. (O custo total é #misss * cost, o mainstream tenta reduzir o primeiro, o Azul o segundo.) Os Java Compute Accelerators da Azul podem ter 20.000 erros de cache simultâneos em andamento e ainda fazer progresso.
Quando a Azul começou, eles pensaram em pegar alguns componentes de E / S disponíveis no mercado e projetar seu próprio núcleo de CPU especializado, mas o que eles realmente precisaram fazer foi exatamente o oposto: eles adotaram um padrão padrão de mercado. prateleira núcleo RISC de 3 endereços e projetou seu próprio controlador de memória, MMU e subsistema de cache.
tl; dr : A "lentidão" do Python não é uma propriedade da linguagem, mas a) sua implementação (primária) ingênua eb) o fato de que as CPUs e sistemas operacionais modernos são projetados especificamente para fazer o C rodar mais rápido e os recursos que eles oferecem. O C para C não está ajudando (cache) ou até prejudicando ativamente o desempenho do Python (memória virtual).
E você pode inserir praticamente qualquer linguagem gerenciada por memória com polimorfismo ad-hoc dinâmico aqui ... quando se trata dos desafios de uma implementação eficiente, até Python e Java são praticamente "a mesma linguagem".