Fiquei feliz em ver que James Hague escolheu O Zen da Programação em Linguagem Assembly como um dos cinco livros memoráveis sobre programação. Concordo plenamente. Mesmo que o senhor nunca planeje tocar em um pedaço de código assembly em toda a sua carreira profissionalesse livro é uma leitura fantástica e muito útil. Eu era um mero Visual Basic quando encontrei este livro (junto com o O Zen da Otimização de Código), peguei o livro de brincadeira e mal consegui largá-lo. É muito bom.
Abrash não é apenas uma figura seminal na comunidade de engenharia de softwareele também é um dos melhores redatores técnicos que o senhor poderá encontrar. É por isso que o ele é um dos meus heróis da programação, diretamente ao lado de Steve McConnell.
Seu Livro Negro de Programação Gráfica é igualmente excelente e aborda tópicos tão gerais e abrangentes que o título se torna um pouco equivocado. O melhor de tudo é que ele é disponível on-line gratuitamente, cortesia da Bytepara que o senhor mesmo possa experimentá-lo.
Eu sei o que o senhor está pensando. “Este livro é sobre gráficos. E linguagem assembly. Além disso, ele é de 1996, que é aproximadamente 1928 em anos de computador. Não tem interesse para mim como programador.” Admita. O senhor tem. Mas sabe o que o senhor vai fazer? O senhor vai clicar de qualquer maneira e ler um pouco. Assim como na faculdade, o tema da aula não importa quando o instrutor é um professor brilhante. E é exatamente isso que Abrash é.
Abrash é um programador e redator técnico de primeira linha, mas também não tem vergonha de explicar os riscos e perigos de nosso ofício, incluindo o maior problema de todos: aquele que fica atrás do teclado. Permita-me ilustrar com uma de minhas passagens favoritas de Abrash, do Capítulo 16 do Livro Negro da Programação Gráfica.
Não faz muito tempo, Terje Mathisen, que apresentei anteriormente neste livro, escreveu um programa de contagem de palavras muito rápido e o publicou no BIX. Quando digo que foi rápido, quero dizer rápido; esse código foi otimizado como ninguém. Estamos falando de código de alta qualidade aqui.
Quando o tópico de otimização surgiu em uma das conferências da BIX, o programa de Terje foi mencionado, e ele postou a seguinte mensagem: “Desafio os BIXens (e especialmente o mabrash!) a acelerá-lo significativamente. Eu consideraria 5% um bom resultado”. A implicação clara era: “Esse código é tão rápido quanto possível”.
Naturalmente, não era; não existe o código mais rápido (TANSTATFC? Concordo, não tem o mesmo toque do TANSTAAFL).
[assembly language tricks and useful optimization approaches elided — see PDF for full detail]
A maior barreira de otimização que Terje enfrentou foi que ele achava que tinha o código mais rápido possível. Quando ele abriu a possibilidade de que havia abordagens mais rápidas e olhou além da abordagem específica que ele havia otimizado com tanto cuidado, ele conseguiu criar um código muito mais rápido. Considere a incongruência da disposição de Terje de considerar significativo um aumento de velocidade de 5% à luz de sua posterior quase o dobro do desempenho.
No mesmo capítulo, o Sr. Abrash relata uma anedota semelhante baseada em um programa de contagem de palavras. Ela foi publicada como um desafio em sua coluna “Pushing the Envelope”:
Esse desafio inicial foi desencadeado por uma coluna que David Gerrold escreveu sobre a questão de contar o número de palavras em um documento; David descobriu alguns problemas de otimização bastante interessantes ao longo do caminho. David fez toda a codificação em Pascal, ressaltando que, embora uma versão em linguagem assembly provavelmente fosse mais rápida, seu utilitário Pascal funcionou corretamente e foi rápido o suficiente para ele.
No entanto, ele não foi rápido o suficiente para mim. O ponto de partida lógico para acelerar a contagem de palavras seria o código Pascal original de David, mas me sinto muito mais confortável com o C, [so I created] uma aproximação livre do programa de contagem de palavras de David, traduzido para C.
Mike passa a fazer o que faz de melhor: otimizar o programa de contagem de palavras em assembly e explicar ao longo do caminho de forma fácil e altamente articulada. Seus resultados são os seguintes:
| Conversão C | 4,6 segundos |
| Conversão de C + assembly | 2,4 segundos |
| Conversão de C + assembly com tabela de pesquisa | 1,6 s |
Em seguida, ele publicou seu programa como um desafio para os leitores da PC Techniques… Será que esse programa de contagem de palavras de montagem otimizada, de um aclamado especialista do setor em otimização de montagem, pode ser ainda melhorado? mais rápido? Bem, acho que o senhor pode adivinhar o que aconteceu em seguida.
Então, como os participantes desse desafio específico se saíram? Mais de um deles alegou um aumento de velocidade de mais de três vezes em relação ao meu código de contagem de palavras em assembly. Além do aumento de velocidade de três vezes em relação ao código C original que eu já havia percebido, estamos quase chegando ao uma ordem de magnitude mais rápida. É claro que o senhor tem direito à sua própria opinião, mas I consideram que uma ordem de magnitude é significativa.
Para falar a verdade, eu não esperava um aumento de velocidade de três vezes; o que eu tinha em mente era cerca de duas vezes. Isso só mostra que qualquer código pode ser mais rápido do que o esperado, se o senhor pensar nele por tempo suficiente e sob várias perspectivas diferentes.
Como Mike disse, não existe o código mais rápido. Se o senhor acha que existe, o senhor está provavelmente é a barreira que impede o desempenho adicional, não o código em si.