Programa espaço de memória para diferentes interpretadores/compiladores

Question

Aqui está um trecho do Taxas de entrada em K linguagem de programação:

O pequeno tamanho do intérprete e compacto sintaxe da linguagem torna possível para K aplicativos para ajustar-se inteiramente dentro do nível 1 cache do processador.

O que, em particular, faz com K programas tão pequeno?Quando se usa ' operador K, map no compilado linguagem funcional como Haskell, ou equivalente for loop em um compilado imperativo linguagem como C, eu não posso imaginar qualquer um compilador gerar radicalmente diferente do código de assembly ou que o que acontece no interpretador internals vai ser muito diferente de for loop.Não há nada de especial em K que torna seu tempo de execução e programas de tão pequeno?

Há um semelhante pergunta sobre ISSO, mas as respostas existem, basicamente, esclarecer nada.

Answer 1

Existem maneiras de gerar um código muito compacto.Por exemplo, um http://en.wikipedia.org/wiki/threaded_code da frente e da mesma forma.É provável que k seja compilado em alguma forma disso.

Answer 2

Eu não sou o autor das taxas declaração acima, apenas alguém que usa a K extensivamente.

Como para o código, K não é de desenrolamento de loops ou fazer outras mudanças para a estrutura de programa que seria o aumento no tamanho além do que você espera.O executável do interpretador em si é pequena.E os programas tendem a ser pequenos (embora não necessariamente).Não é a execução de quaisquer instruções de mapeamento, etc.é mais provável que o próprio código irá executar todas as dentro de cache.

K programas tendem a ser pequenos, porque eles são um pequeno, apertado bytecode em armazenamento, e de sua sintaxe, tende a produzir quantidades muito pequenas de código para uma determinada operação.

Compare este programa em Java:

int r=0;
for(int i=0; i<100; i++) {
  r+=i;
}

Contra este K programa produzir o mesmo resultado:

+/!100

A quantidade de código a ser executado é semelhante, mas o armazenamento necessário para o programa (muito menos de escrever!) é muito menor.K é ótimo para aqueles com lesões por esforço repetitivo.

Como para os dados, o incentivo para o trabalho em vários itens de dados com o único instruções tende a tornar o acesso sequencial, de uma forma amigável para o cache, em vez de acesso aleatório.Tudo isso apenas torna mais provável que o programa vai ser de cache amigável.

Mas isso tudo é apenas tendências e as melhores práticas dentro da linguagem em combinação com o K executável propriamente dito.Se você vincular em grandes quantidades de código adicional, caso especial muitas funções, e randomize índices antes de acessar os dados, o programa vai ser tão hostil para o cache, como seria de esperar.