Como uma linguagem cujo compilador é escrito em C pode ser mais rápida que C?

Dando uma olhada na página de Julia , você pode ver alguns benchmarks de vários idiomas em vários algoritmos (horários mostrados abaixo). Como um idioma com um compilador originalmente escrito em C pode superar o código C?

Figura: tempos de referência em relação a C (quanto menor, melhor, desempenho de C = 1,0).

Não há relação necessária entre a implementação do compilador e a saída do compilador. Você poderia escrever um compilador em uma linguagem como Python ou Ruby, cuja maioria das implementações comuns são muito lento, e que compilador poderia saída altamente otimizado código de máquina capaz de superando C. O compilador em si levaria um longo tempo para executar, porque suao código é escrito em um idioma lento. (Para ser mais preciso, escrito em um idioma com uma implementação lenta. Os idiomas não são realmente intrinsecamente rápidos ou lentos, como Raphael aponta em um comentário. Eu expiro essa idéia abaixo.) O programa compilado seria o mais rápido possível. própria implementação permitida - poderíamos escrever um compilador em Python que gere o mesmo código de máquina que um compilador Fortran, e nossos programas compilados seriam tão rápidos quanto o Fortran, mesmo que demorassem muito tempo para compilar.

É uma história diferente se estamos falando de um intérprete. Os intérpretes precisam estar em execução enquanto o programa que eles estão interpretando estiver em execução, para que haja uma conexão entre o idioma em que o intérprete é implementado e o desempenho do código interpretado. É preciso uma otimização inteligente do tempo de execução para criar uma linguagem interpretada que seja mais rápida que a linguagem na qual o intérprete é implementado, e o desempenho final pode depender de quão acessível é um pedaço de código para esse tipo de otimização. Muitas linguagens, como Java e C #, usam tempos de execução com um modelo híbrido que combina alguns dos benefícios dos intérpretes com alguns dos benefícios dos compiladores.

Como um exemplo concreto, vamos olhar mais de perto o Python. Python tem várias implementações. O mais comum é o CPython, um intérprete de bytecode escrito em C. Há também o PyPy, que é escrito em um dialeto especializado do Python chamado RPython, e que usa um modelo de compilação híbrido, semelhante à JVM. O PyPy é muito mais rápido que o CPython na maioria dos benchmarks; ele usa todos os tipos de truques incríveis para otimizar o código em tempo de execução. No entanto, a linguagem Python que o PyPy executa é exatamente a mesma linguagem Python que o CPython, exceto algumas diferenças que não afetam o desempenho.

Suponha que escrevemos um compilador na linguagem Python para o Fortran. Nosso compilador produz o mesmo código de máquina que o GFortran. Agora compilamos um programa Fortran. Podemos executar nosso compilador no topo do CPython, ou no PyPy, pois ele está escrito em Python e ambas as implementações executam a mesma linguagem Python. O que descobriremos é que, se rodarmos nosso compilador no CPython, rodar no PyPy, compilar a mesma fonte Fortran com o GFortran, obteremos exatamente o mesmo código de máquina nas três vezes, para que o programa compilado sempre seja executado na mesma velocidade. No entanto, o tempo necessário para produzir esse programa compilado será diferente. O CPython provavelmente levará mais tempo que o PyPy, e o PyPy provavelmente levará mais tempo que o GFortran, mesmo que todos eles produzam o mesmo código de máquina no final.

Ao digitalizar a tabela de benchmark do site Julia, parece que nenhum dos idiomas executados nos intérpretes (Python, R, Matlab / Octave, Javascript) possui benchmarks em que eles batem em C. Isso geralmente é consistente com o que eu esperaria ver, embora eu possa imaginar o código escrito com a biblioteca Numpy altamente otimizada do Python (escrita em C e Fortran) superando algumas implementações possíveis em C de código semelhante. As linguagens iguais ou melhores que C estão sendo compiladas (Fortran, Julia ) ou usando um modelo híbrido com compilação parcial (Java e, provavelmente, LuaJIT). O PyPy também usa um modelo híbrido, por isso é perfeitamente possível que, se rodássemos o mesmo código Python no PyPy, em vez do CPython, realmente o veríamos vencer C em alguns benchmarks.

Como uma máquina construída por um homem pode ser mais forte que um homem? Esta é exatamente a mesma pergunta.

A resposta é que a saída do compilador depende dos algoritmos implementados por esse compilador, não da linguagem usada para implementá-lo. Você pode escrever um compilador realmente lento e ineficiente que produz código muito eficiente. Não há nada de especial em um compilador: é apenas um programa que recebe alguma entrada e produz alguma saída.

Quero argumentar contra uma suposição comum que, em minha opinião, é falaciosa a ponto de ser prejudicial ao escolher ferramentas para um emprego.

Não existe uma linguagem lenta ou rápida. ¹

No caminho para a CPU realmente fazendo alguma coisa, há muitos passos².

1. Pelo menos um programador com certas habilidades.
2. O idioma (formal) em que eles programam ("código fonte").
3. As bibliotecas que eles usam.
4. Algo que traduz o código fonte em código de máquina (compiladores, intérpretes).
5. A arquitetura geral do hardware, por exemplo, número de unidades de processamento e layout da hierarquia de memória.
6. O sistema operacional que gerencia o hardware.
7. Otimizações na CPU.

Cada item contribui para o tempo de execução real que você pode medir, às vezes intensamente. Diferentes "idiomas" se concentram em coisas diferentes³.

Apenas para dar alguns exemplos.

• 1 vs 2-4 : é provável que um programador C médio produza código muito pior que um programador Java comum, tanto em termos de correção quanto de eficiência. Isso ocorre porque o programador tem mais responsabilidades em C.

• 1/4 vs 7 : em linguagem de baixo nível como C, você pode explorar certos recursos da CPU como programador . Em linguagens de nível superior, apenas o compilador / intérprete pode fazê-lo e somente se conhecerem a CPU de destino.

• 1/4 vs 5 : você deseja ou precisa controlar o layout da memória para melhor utilizar a arquitetura de memória disponível? Alguns idiomas dão a você controle sobre isso, outros não.

• 2/4 vs 3 : O próprio Python interpretado é terrivelmente lento, mas existem ligações populares para bibliotecas compiladas nativamente altamente otimizadas para computação científica. Portanto, fazer certas coisas no Python é rápido no final, se a maior parte do trabalho for feita por essas bibliotecas.

• 2 vs 4 : O intérprete Ruby padrão é bastante lento. O JRuby, por outro lado, pode ser muito rápido. Esse mesmo idioma é rápido usando outro compilador / intérprete.

• 1/2 vs 4 : Usando otimizações do compilador, código simples pode ser traduzido em código de máquina muito eficiente.

O ponto principal é que a referência que você encontrou não faz muito sentido, pelo menos não quando resumida à tabela que você inclui. Mesmo se tudo o que você está interessado é no tempo de execução, você precisa especificar toda a cadeia, do programador à CPU; a troca de qualquer um dos elementos pode alterar drasticamente os resultados.

Para ser claro, isso responde à pergunta porque mostra que o idioma em que o compilador (etapa 4) está escrito é apenas uma peça do quebra-cabeça e provavelmente não é relevante (veja outras respostas).

1. Certamente, existem recursos de linguagem que são mais caros de implementar do que outros. Mas a existência de recursos não significa que você precise usá-los, e um recurso caro pode economizar o uso de muitos mais baratos e, portanto, pagar no final. (De outras vantagens não mensuráveis ​​em tempo de execução.)
2. Eu pulo o nível algorítmico porque nem sempre se aplica e é principalmente independente da linguagem de programação usada. Lembre-se de que algoritmos diferentes se prestam melhor a diferentes hardwares, por exemplo.

3. Eu deliberadamente não entro em métricas de sucesso diferentes aqui: eficiência do tempo de execução, eficiência da memória, tempo do desenvolvedor, segurança, segurança, exatidão (comprovável?), Suporte à ferramenta, independência da plataforma, ...

   Comparar idiomas usando uma métrica, mesmo tendo sido projetados para objetivos completamente diferentes, é uma enorme falácia.

Há uma coisa esquecida sobre otimização aqui.

Houve um longo debate sobre o desempenho do fortran C. Separando o debate malformado: o mesmo código foi escrito em C e fortran (como os testadores pensavam) e o desempenho foi testado com base nos mesmos dados. O problema é que essas linguagens diferem, C permite que o ponteiro faça alias, enquanto o fortran não.

Portanto, os códigos não eram os mesmos, não havia restrição de __ nos arquivos testados em C, o que deu diferenças, depois de reescrever os arquivos para informar ao compilador que ele pode otimizar ponteiros, os tempos de execução se tornam semelhantes.

O ponto aqui é que algumas técnicas de otimização são mais fáceis (ou começam a ser legais) no idioma recém-criado.

$X$

Em segundo lugar, a VM pode executar o teste de pressão durante a execução, para que ele possa pegar o código pressionado e otimizar ou até pré-calcular durante o tempo de execução. O programa C compilado antecipadamente não espera onde está a pressão ou (na maioria das vezes) há versões genéricas de executáveis ​​para a família geral de máquinas.

Nesse teste, também há JS, bem, existem VMs mais rápidas que a V8 e também executam mais rápido que C em alguns testes.

Eu verifiquei e havia técnicas exclusivas de otimização ainda não disponíveis nos compiladores C.

O compilador C teria que fazer uma análise estática de todo o código de uma só vez, marchar sobre a plataforma e resolver problemas de alinhamento de memória.

A VM apenas transliterou parte do código para otimizar a montagem e executá-la.

Sobre Julia - como eu verifiquei, ele opera em AST de código, por exemplo, o GCC pulou esta etapa e recentemente começou a obter algumas informações a partir daí. Isso, além de outras restrições e técnicas de VM, pode explicar um pouco.

Exemplo: vamos dar um loop simples, que pega o ponto final final das variáveis ​​e carrega parte das variáveis ​​nos cálculos conhecidos no tempo de execução.

O compilador C gera variáveis ​​de carregamento dos registradores.
Porém, no tempo de execução, essas variáveis ​​são conhecidas e tratadas como constantes através da execução.
Portanto, em vez de carregar variáveis ​​dos registradores (e não executar o armazenamento em cache porque pode mudar, e da análise estática não está claro), elas são tratadas completamente como constantes e dobradas, propagadas.

As respostas anteriores dão praticamente a explicação, embora principalmente de um ângulo pragmático, tanto quanto a pergunta faz sentido , como excelentemente explicado pela resposta de Raphael .

Acrescentando a esta resposta, devemos observar que, atualmente, os compiladores C são escritos em C. Obviamente, como observou Raphael, sua saída e seu desempenho podem depender, entre outras coisas, da CPU em que está sendo executada. Mas isso também depende da quantidade de otimização feita pelo compilador. Se você escreve em C um compilador de otimização melhor para C (que você compila com o antigo para poder executá-lo), você obtém um novo compilador que torna C uma linguagem mais rápida do que era antes. Então, qual é a velocidade de C? Observe que você pode até compilar o novo compilador consigo mesmo, como uma segunda passagem, para que ele seja compilado com mais eficiência, embora ainda dê o mesmo código de objeto. E o teorema do pleno emprego mostra que não há fim para essas melhorias (obrigado Raphael pelo ponteiro).

Mas acho que pode valer a pena tentar formalizar a questão, pois ilustra muito bem alguns conceitos fundamentais e, particularmente, a visão denotacional versus operacional das coisas.

O que é um compilador?

$C_{S\to T}$$C$$\mathcal C_{S\to T}$$P_{:S}$$\mathcal P$ $S$$P_{:T}$ $T$$\mathcal P$

$\mathcal C_{S\to T}$$C_{S\to T}$$\{(P_{:S},P_{:T})\mid P_S\in S \wedge P_T\in T\}$

$\mathcal C_{S\to T}$$P_S$$P_T$$\mathcal P$

$P_{:T}$$P_{:S}$$\mathcal C_{S\to T}$

Refinando o argumento, provavelmente queremos que o compilador tenha uma boa eficiência, para que a tradução possa ser realizada em tempo razoável. Portanto, o desempenho do programa do compilador é importante para os usuários, mas não tem impacto na semântica. Estou dizendo desempenho, porque a complexidade teórica de alguns compiladores pode ser muito maior do que se poderia esperar.

Sobre a inicialização

Isso ilustrará a distinção e mostrará uma aplicação prática.

$S$$I_S$$C_{S\to T\,:S}$$S$$C_{S\to T\,:S}$$I_S$$P_{:S}$$P_{:T}$$S$$T$

$C_{S\to T\,:S}$$S$$C_{S\to T\,:T}$$T$$T$$T$

Pelo teorema da velocidade de Blum, existem programas que são escritos e executados na combinação computador / compilador mais rápida, que serão executados mais lentamente que um programa para o mesmo no seu primeiro PC executando o BASIC interpretado. Simplesmente não existe um "idioma mais rápido". Tudo o que você pode dizer é que, se você escrever o mesmo algoritmo em várias linguagens (implementações; como observado, existem muitos compiladores C diferentes por aí, e eu até me deparei com um intérprete C bastante capaz), ele será executado mais rápido ou mais devagar em cada .

Não pode haver uma hierarquia "sempre mais lenta". Este é um fenômeno que todo mundo fluente em várias linguagens conhece: Cada linguagem de programação foi projetada para um tipo específico de aplicativo, e as implementações mais usadas foram otimizadas para esse tipo de programa. Tenho certeza de que, por exemplo, um programa para brincar com seqüências de caracteres escritas em Perl provavelmente vencerá o mesmo algoritmo escrito em C, enquanto um programa mastigando grandes matrizes de números inteiros em C será mais rápido que o Perl.

Vamos voltar à linha original: "Como uma linguagem cujo compilador é escrito em C pode ser mais rápida que C?" Eu acho que isso realmente significava dizer: como um programa escrito em Julia, cujo núcleo está escrito em C, pode ser mais rápido que um programa escrito em C? Especificamente, como o programa "mandel", escrito em Julia, pode ser executado em 87% do tempo de execução do programa "mandel" equivalente, escrito em C?

O tratado de Babou é a única resposta correta até agora. Todas as outras respostas até agora estão respondendo mais ou menos a outras perguntas. O problema com o texto de babou é que a descrição teórica de "O que é um compilador" com muitos parágrafos é escrita em termos que o pôster original provavelmente terá problemas para entender. Quem entende os conceitos mencionados pelas palavras "semântica", "denotacionalmente", "realização", "computável" e assim por diante já saberá a resposta para a pergunta.

A resposta mais simples é que nem o código C nem o código Julia são diretamente executáveis ​​pela máquina. Ambos precisam ser traduzidos, e esse processo de tradução apresenta muitas maneiras pelas quais o código de máquina executável pode ser mais lento ou mais rápido, mas ainda produz o mesmo resultado final. C e Julia fazem compilação, o que significa uma série de traduções para outra forma. Geralmente, um arquivo de texto legível por humanos é traduzido para alguma representação interna e, em seguida, gravado como uma sequência de instruções que o computador pode entender diretamente. Em alguns idiomas, há mais do que isso, e Julia é uma delas - possui um compilador "JIT", o que significa que todo o processo de tradução não precisa acontecer de uma só vez para todo o programa. Mas o resultado final para qualquer idioma é o código de máquina que não precisa de tradução adicional, código que pode ser enviado diretamente à CPU para fazer alguma coisa. No final, ESTA é a "computação", e há mais de uma maneira de dizer à CPU como obter a resposta desejada.

Pode-se imaginar uma linguagem de programação que tenha um operador "mais" e um "multiplique", e outra linguagem que tenha apenas "mais". Se o seu cálculo exigir multiplicação, um idioma será "mais lento", porque é claro que a CPU pode fazer as duas coisas diretamente, mas se você não tiver como expressar a necessidade de multiplicar 5 * 5, você precisará escrever "5 + 5 + 5 + 5 + 5 ". Este último levará mais tempo para chegar à mesma resposta. Presumivelmente, há algo disso acontecendo com Julia; talvez a linguagem permita ao programador declarar o objetivo desejado de calcular um conjunto de Mandelbrot de uma maneira que não seja possível expressar diretamente em C.

O processador usado para o benchmark foi listado como uma CPU Xeon E7-8850 2.00GHz. O benchmark C usou o compilador gcc 4.8.2 para produzir instruções para essa CPU, enquanto Julia usa a estrutura do compilador LLVM. É possível que o back-end do gcc (a parte que produz o código da máquina para uma arquitetura de CPU específica) não seja tão avançado de alguma forma quanto o back-end do LLVM. Isso pode fazer a diferença no desempenho. Também há muitas outras coisas acontecendo - o compilador pode "otimizar", talvez emitindo instruções em uma ordem diferente da especificada pelo programador, ou até mesmo não fazendo nada, se puder analisar o código e determinar que não está. necessário para obter a resposta certa. E o programador pode ter escrito parte do programa C de uma maneira que o torna lento, mas não o fez

Todas essas são maneiras de dizer: existem várias maneiras de escrever código de máquina para calcular um conjunto de Mandelbrot, e o idioma que você usa tem um efeito importante sobre como esse código de máquina é escrito. Quanto mais você entender sobre compilação, conjuntos de instruções, caches, etc., mais equipado estará para obter os resultados desejados. A principal vantagem dos resultados de referência citados para Julia é que nenhum idioma ou ferramenta é melhor em tudo. De fato, o melhor fator de velocidade em todo o gráfico foi para Java!

A velocidade de um programa compilado depende de duas coisas:

1. As características de desempenho da máquina que a executa
2. O conteúdo do arquivo executável

O idioma em que o compilador está escrito é irrelevante para (1). Por exemplo, um compilador Java pode ser escrito em C ou Java ou Python, mas em todos os casos a "máquina" que executa o programa é a JVM.

O idioma em que o compilador está escrito é irrelevante para (2). Por exemplo, não há razão para que um compilador C escrito em Python não possa gerar exatamente o mesmo arquivo executável que um compilador C escrito em C ou Java.

Vou tentar oferecer uma resposta mais curta.

O cerne da questão está na definição de "velocidade" de uma linguagem .

A maioria, se não todos os testes de comparação de velocidade, não testam qual é a velocidade máxima possível. Em vez disso, eles escrevem um pequeno programa em um idioma que desejam testar, para resolver um problema. Ao escrever o programa, o programador usa o que eles assumem * como melhores práticas e convenções do idioma, no momento do teste. Eles medem a velocidade com que o programa foi executado.

* As suposições estão ocasionalmente erradas.

O código escrito em uma linguagem X, cujo compilador é escrito em C, pode superar um código escrito em C, desde que o compilador C faça uma otimização ruim em comparação com a linguagem X. Se mantivermos a otimização fora de discussão, se o compilador de X puder gerar melhor código de objeto diferente daquele gerado pelo compilador C, o código escrito em X também pode vencer a corrida.

Mas se a linguagem X é uma linguagem interpretada e o intérprete é escrito em C, e se assumirmos que o intérprete da linguagem X e o código escrito em C são compilados pelo mesmo compilador C, de maneira alguma o código escrito em X superará o código escrito em C, desde que a implementação siga o mesmo algoritmo e use estruturas de dados equivalentes.