Qual é o significado da frase "queríamos que fosse compilada para não queimar a CPU fazendo as coisas erradas".

10

Eu estava lendo este artigo. Possui o seguinte parágrafo.

E Scala acabou sendo rápido? Bem, qual é a sua definição de rápido? Tão rápido quanto Java. Não precisa ser tão rápido quanto C ou Assembly. Python não é significativamente mais rápido que Ruby. Queríamos fazer mais com menos máquinas, aproveitando melhor a concorrência; queríamos que fosse compilado para que não estivesse queimando a CPU fazendo as coisas erradas.

Estou procurando o significado da última frase. Como a linguagem interpretada fará com que a CPU faça coisas "erradas"?

performance cpu compilation

— user2434
fonte

3

Chamar qualquer coisa que compila o código de bytes da JVM interpretado é um pouco liberal com o uso.

— Rig

47

Se o código diz

A = A + 1

código compilado faz isso

add A, 1

código interpretado faz isso (ou alguma variação)

look up the location of A in the symbol table
find the value of A
see that 1 is a constant
get its value
add the value of A and the value of 1
look up the location of A in the symbol table
store the new value of A

entendeu a ideia?

— Mike Dunlavey
fonte

3

Às vezes oversimplification realmente faz tornar a imagem mais clara ;-) (apenas para ser completo: muitos intérpretes conhecido poços otimizar alguns dos passos de distância, por isso eles são meio caminho entre as duas amostragens "implementações" aqui).

— Joachim Sauer

3

@JoachimSauer: Você está certo, é claro. Ainda é difícil executar um intérprete com menos de um fator de penalidade de 10 velocidades em comparação com o código compilado. Se a linguagem realmente passa todo o seu tempo em funções subordinadas compiladas que precisam ser chamadas de qualquer maneira, como bibliotecas de matemática ou E / S, o custo da interpretação não é um problema.

— Mike Dunlavey

11

Esta é uma descrição incrível

— Jamie Taylor

13

queríamos que fosse compilado para que não estivesse queimando a CPU fazendo as coisas erradas.

Parece que eles estão se referindo a compilados versus interpretados. Provavelmente, toda a história do Twitter mudou as tarefas de processamento em segundo plano para o Scala (compilado) após o desenvolvimento inicial no Ruby On Rails (interpretado).

Uma explicação do código compilado versus código interpretado aqui .

Com um idioma compilado, o código digitado é reduzido a um conjunto de instruções específicas da máquina antes de ser salvo como um arquivo executável. Com idiomas interpretados, o código é salvo no mesmo formato que você inseriu. Os programas compilados geralmente são executados mais rapidamente que os interpretados porque os programas interpretados devem ser reduzidos às instruções da máquina em tempo de execução.

— KrisG
fonte

É um prazer dar-lhe o seu primeiro +1. Bem-vindo ao P.SE!

— haylem

4

(Vale a pena mencionar que o Scala - como está na JVM - é tecnicamente apenas compilado em bytes).

— haylem

Não sabia que Scala era baseado em JVM. Significando que é provavelmente JIT compilado. Nesse caso, por que o Twitter não mudou do Ruby on Rails para o JRuby? Você pensaria que seria uma migração mais fácil com o benefício da compilação.

— KrisG

3

Eles também estavam procurando um melhor modelo de concorrência e tinham problemas com a coleta de lixo do Ruby. O artigo descreve em detalhes.

— scrwtp

9

"Coisas erradas" aqui significam a sobrecarga necessária para o intérprete analisar e processar o código. Está ligado à noção de linguagens interpretadas versus linguagens compiladas. Existem vários modelos de tradução de código em uso, que se enquadram aproximadamente em uma das seguintes categorias:

Compilação nativa - o código fonte é diretamente compilado no código da máquina. Melhor desempenho às custas da portabilidade. Comumente associado a C e C ++,
Compilação intermediária - o código-fonte é compilado em uma linguagem intermediária simplificada (bytecode), que é posteriormente interpretada ou compilada (compilação just-in-time) no código da máquina durante a execução. Melhor portabilidade do que o código nativo, melhor desempenho do que a interpretação pura, mantendo algumas das vantagens da interpretação (como ligação tardia). Os exemplos incluem C #, Java e outras linguagens direcionadas à JVM e .NET CLR,
Interpretação - o código fonte não é traduzido diretamente em código de máquina, mas é interpretado e executado por um programa de intérprete dedicado. Os intérpretes variam em sofisticação, na implementação ingênua, no entanto, tudo se resume a analisar, analisar e executar o código fonte linha por linha. A interpretação permite maior flexibilidade do que a compilação; portanto, linguagens interpretadas fazem uso mais amplo de digitação ou reflexão dinâmica, por exemplo. As linguagens interpretadas costumam ser vistas como oferecendo maior produtividade ao desenvolvedor, pois exigem menos código padrão e se prestam de maneira agradável à prototipagem rápida. A desvantagem é o desempenho reduzido. Comumente associado ao JavaScript, Ruby ou Python.

Portanto, a escolha entre linguagem interpretada e compilada se resume à questão: o que mais valorizamos, produtividade ou desempenho do desenvolvedor? A migração descrita no artigo parece seguir a mesma linha de pensamento, com a forte linguagem de prototipagem Ruby sendo substituída pelo Scala baseado em JVM devido a considerações de desempenho.

— scrwtp
fonte

-1 da maneira como a resposta é formulada, parece muito simplista. Ele ignora completamente coisas como JIT ( compilação just-in-time ) - que é a maneira como o Scala atropela a JVM / CLR #

— 406

Verdade. Reescrevendo a resposta, estava adicionando pouco ao tópico por assim dizer.

— scrwtp 12/06

-3

Nesse caso, entendi the wrong stuffa falta de segurança de tipo no código não compilado.

Assim, não apenas o código interpretado é mais lento, como também é mais complicado ...

— Neil Twist
fonte

8

Você está assumindo que as linguagens compiladas são seguras e as interpretadas não são. Há muitos exemplos contrários Por exemplo lisp podem ser compilados e não é fortemente tipado, enquanto Haskell pode ser interpretado e é muito tipo seguro

— Zachary K

11

Igualar "não digitar seguro" com "mais buggy" é FUD pressionado por pessoas com produtos para vender.

— user16764

11

@ user16764: Não é FUD se é verdade. Na IME, as pessoas que fazem bobagens sobre o assunto para vender produtos são as que tentam menosprezar o vínculo entre digitação dinâmica e erros. ("É apenas um tipo de erro " etc.)

— Mason Wheeler