Quais dessas antigas críticas ao cisco comum ainda se aplicam hoje?


29

Em A Critique of Common Lisp, escrito por Rodney A. Brooks e Richard P. Gabriel, de Stanford, em 1984, são discutidas algumas decisões de design retidas pelo comitê de normalização do Common Lisp. Embora a maior parte da discussão permaneça válida, há duas declarações que se referem à tecnologia disponível no momento e podem ser falsas hoje.

Essas duas instruções são:

Muitos custos do idioma foram descartados com a advertência de que "qualquer bom compilador" pode cuidar deles. Ninguém ainda escreveu - nem é provável que sem um esforço tremendo - um compilador que faz uma fração dos truques esperados dele.

Como sou um novato no Common Lisp, ou mesmo um aprendiz, não sou capaz de ser mais específico do que os autores. Eles parecem afirmar que uma grande generalidade e flexibilidade foi incorporada a vários aspectos da linguagem, o que dificulta a escrita de um bom compilador.

No LISP COMUM, um controle excessivo foi colocado na aritmética de ponto flutuante. E certamente, embora o comportamento correto de um programa intensivo de ponto flutuante possa ser alcançado, o desempenho pode variar bastante.

Pelo que entendi, parece que escrever código numérico eficiente no Common Lisp é possível, mas é mais desafiador do que deve ser.

Isso foi há trinta anos. Como devo considerar essa afirmação hoje se estou disposto a escrever programas Common Lisp para uma das implementações comuns de software livre (CLISP, SBCL et al.)?


Ótima pergunta! Gostaria de ouvir alguém com conhecimento sobre o Common Lisp sobre este tópico. Meu medo é que eles ainda se apliquem, com base na aparente popularidade relativa do Common Lisp atualmente.

1
É difícil acertar o ponto flutuante. Algumas linguagens especificam um modelo estrito e sofrem desempenho, outras usam um modelo flexível e são difíceis de raciocinar. Por exemplo, raciocinar sobre programas simples de ponto flutuante em C # é muito difícil para mim. Por isso, tenho a tendência de apoiar designers de linguagem que sejam rigorosos com o ponto flutuante, mesmo que custe o desempenho.
CodesInChaos

2
Por outro lado, hardware moderno geralmente implementa IEEE ponto flutuante, por isso é provavelmente muito mais previsível em seu comportamento do que as implementações disponíveis em 1984.
microtherion

Respostas:


31

O artigo é interessante de várias maneiras.

A parte mais interessante é a seguinte: os autores falsificaram o artigo de 1984 apenas dois anos depois, em 1986. Brooks e Gabriel desenvolveram um compilador Lisp altamente otimizado e o venderam com muito sucesso comercial por vários anos: Lucid Common Lisp (PDF).

A manutenção desse compilador Lisp ainda está disponível no LispWorks : agora é chamada Liquid Common Lisp .

As otimizações do compilador do Liquid CL estão documentadas no Capítulo 3 do Advanced User Guide : Optimizing Lisp Programs .

Várias aplicações comerciais foram escritas e implantadas no Lucid CL. Por exemplo, em minha cidade natal, o primeiro sistema de informações de transporte público para o HVV (Hamburger Verkehrsverbund) foi implantado usando o Lucid CL em uma estação SPARC da SUN. Estava disponível para o público nas estações de trem, usando uma grande tela sensível ao toque e no call center.

O Lucid CL foi bem-sucedido porque seu compilador de modo de produção criou aplicativos Common Lisp rápidos, principalmente para plataformas Unix / RISC.

Brooks e Gabriel estão escrevendo sobre Lucid Common Lisp em 1986:

O compilador dinamicamente redirecionável foi mostrado como um meio pelo qual a facilidade de compilação para uma variedade de implementações do Lisp pode ser realizada; um meio de portar sistemas Lisp para uma variedade de computadores; e uma ferramenta para produzir código de alta qualidade e alto desempenho para uma variedade de computadores de uma fonte comum.

Assim, eles acabaram de implementar o que a Crítica do Common Lisp afirmava ser difícil ou impossível.

Atualmente, as implementações mais avançadas estão fazendo muitas otimizações, mas o hardware também é 1000 vezes mais rápido que o que tínhamos em 1984. Um VAX 11/780 tinha um MIPS (milhão de instruções por segundo) e uma máquina Lisp também estava em uso. esse intervalo. Um Motorola 68000 tinha uma taxa de clock de 8 MHz.

As críticas ao desempenho do ponto flutuante e ao desempenho geralmente variável ainda são válidas, mas isso reflete a escolha dos implementadores. Algumas implementações não são desenvolvidas como compiladores de alto desempenho. Seu foco principal pode ser portabilidade, compacidade ou outra coisa e, portanto, eles têm objetivos de implementação diferentes.

Como usuário / desenvolvedor, não é necessário escrever código portátil e usar todos os dez sistemas Common Lisp atualmente suportados. Use a implementação mais adequada ao problema do aplicativo.


Sua resposta é muito precisa e detalhada, definitivamente merece a recompensa!
user40989

1
"Altamente otimizado" não significa necessariamente que o compilador seja "suficientemente inteligente". As palavras "suficientemente inteligente" levantam a questão "com que finalidade?". Ainda existem aplicativos (principalmente para plataformas incorporadas muito limitadas) que você não escreveria no Common Lisp porque a otimização ainda não pode eliminar todas as despesas de tempo de execução da digitação dinâmica, alocação de heap e coleta de lixo. É claro que o Common Lisp não é de forma alguma único nesse "fracasso". Nenhuma linguagem foi observada na natureza ainda que seja genuinamente adequada a absolutamente tudo.
Steve314

@ Steve314: Os alvos do Lucid CL eram o mercado para grandes sistemas de IA baseados em Lisp, sistemas CAD, etc. em estações de trabalho e servidores Unix. O alvo do Lucid CL não era sistemas embarcados. O Lucid CL aborda a sobrecarga em tempo de execução da digitação dinâmica, alocação de heap e muitas outras áreas de otimização - incluindo um coletor de lixo de alto desempenho. Ainda, o GC é principalmente necessário. Normalmente, os aplicativos usam técnicas especiais para evitar o consumo e, assim, reduzir a taxa de GC, como os conjuntos de 'recursos'.
Rainer Joswig 12/12/13

21

Quando este artigo foi escrito em 1984, um computador com 1 megabyte de RAM e um disco rígido de 20 megabytes, capaz de se sentar em sua mesa, era um grande negócio. Naturalmente, surgirão disputas sobre a praticidade de uma linguagem de alto nível como Lisp em hardware espartano. Os avanços na tecnologia de hardware e compilador que ocorreram desde então tornaram os programas Lisp muito mais fáceis de escrever e executar, independentemente de quaisquer ineficiências numéricas que possam estar presentes no idioma.

Os programadores geralmente trocam eficiência computacional por eficiência de programação. O Lisp pode ser uma linguagem lenta (em algumas implementações, mas também em outras linguagens), mas também possui uma reputação bem merecida de desenvolvimento rápido, e muitos programas não exigem uma infraestrutura altamente otimizada para exibir desempenho adequado.

A escolha da implementação do Lisp pode afetar muito o perfil de desempenho dos seus programas. Por exemplo, o CLISP admite prontamente que "Se o seu código for muito numérico, você poderá preferir o CMUCL". Várias implementações modernas de Lisp (e Scheme) permitem especificar dicas de tipo numérico, o que aumentará o desempenho numérico.

Em suma, a situação está muito melhor hoje do que era então.

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.