Spectre obriga a um código mais elegante

Escreva-o bem, escreva-o com eficiência, escreva-o como se o hardware subjacente não fosse tornar-se mais rápido. Porque não vai.

Num futuro próximo, os programadores vão ter de se habituar a escrever código para hardware mais lento. Além do abrandamento noticiado após a instalação de algumas correcções Meltdown, o problema de longo prazo é a Spectre. Como o nome deixa antever, esta falha vai assombrar o mundo nos próximos anos.

A Spectre vai continuar a manifestar-se. Para a mitigar será necessário a recompilação de aplicações com novas instruções que funcionem em torno de vulnerabilidades executáveis especulativas.

Mas, isto acaba por ser o equivalente a tentar curar uma fractura com um penso rápido. Fundamentalmente, precisamos de novos desenhos de processadores, que trabalhem de forma diferente, porque os que temos agora não são seguros. Infelizmente, novos designs de CPU não deverão aparecer brevemente.

Para muitos projectos de desenvolvimento de software, a falta de segurança total poderá não ser particularmente relevante. O risco de os sistemas serem comprometidos é bastante baixo e não está provado que exista, pelo menos para já. Mas há aplicações críticas que requerem um nível mais elevado de segurança de dados do que “provavelmente, ok”. 

Há alguns sistemas imunes ao Spectre, mas tendem a ser lentos, antigos ou ambos. O Raspberry Pi é um, os processadores pré-Atom da Intel são outros.

Não executam instruções de forma não-sequencial (out-of-order), mas também não fazem nada particularmente depressa. Este é agora o dilema de todos os que se preocupam com a segurança: rápido e falível ou lento e seguro (ou pelo menos mais seguro).

Os programadores de software devem tomar medidas e fazer a diferença.

Até que isto mude, até que a nova geração de processadores acabe por contornar as falhas e nos dê uma computação de velocidade total, sem a execução de vulnerabilidades especulativas, os programadores de software devem tomar medidas e fazer a diferença.

Sim, a programação de código eficiente está, de repente, novamente na moda, porque os programadores não podem continuar a assumir que o hardware de amanhã será mais rápido do que o de hoje. Mas, o que significa isto em termos de desenvolvimento?

Para o processamento paralelo em múltiplos núcleos, isso significa uma melhor compreensão dos fluxos de trabalho na aplicação em desenvolvimento, o que é difícil. Descobrir que partes de um fluxo de trabalho de uma aplicação podem ser separadas, processadas em paralelo e depois recombinadas, requer mais do que uma mera compreensão do código da aplicação.

Requer perceber o que está na cabeça do utilizador. Como é que os utilizadores vão utilizar determinada função? Que fluxos de dados irão precisar de mais trabalho?

A questão é um pouco mais simples em aplicações de servidor automatizadas, mas apenas um pouco mais, porque alguns processos não se prestam à paralelização. Até dividir um ficheiro de vídeo para conversão por múltiplos núcleos ou segmentos é mais difícil do que parece.

Infelizmente, muito do que fazemos na computação depende do que acabámos de fazer. Tal como no mundo real, a ordem é importante. Não há almoços grátis e a paralelização tem as suas limitações: aplica-se a lei de Amdahl.

Depois existe o desempenho de encadeamento único, agora limitado, à força, pelas falhas de execução especulativas. Segmentar arquitecturas ordenadas, como a Atom, significaria criar software mais eficiente que é cuidadosamente escrito, em vez de misturar tudo sem pensar muito na optimização. O Kolibri, por exemplo, voa na minha antiga máquina Atom.

A sua próxima aplicação não será provavelmente escrita por integração, mas não será necessário aproximar-se demasiado do hardware subjacente para descobrir truques para melhorar o desempenho que irá reduzir alguns ciclos aqui e ali. Possivelmente, a maioria do software vendido actualmente poderia ser mais rápido – mesmo muito mais rápido – com os recursos de desenvolvimento necessários.

Mas implementar melhor código com eficiência vai ser um desafio enorme. A pressão comercial sobre as equipas de desenvolvimento significa que qualquer tentativa de escrever código elegamente e optimizado tendencialmente passará para segundo plano em relação, por exemplo, à necessidade de conclusão.  Como diriam os gestores de projectos: “Já passaram seis semanas sobre o prazo [irrealista] e o produto tem de ser entregue segunda-feira, por isso, esqueçam a qualidade e despachem isso!”

A eficiência e a optimização do código estão a definhar há anos, porque outros factores parecem ser mais importantes. Os resultados estão à vista. Todos nós já experimentamos uma nova versão de um produto que requer muito mais recursos que os seus predecessores.

A eficiência e a optimização do código estão a definhar há anos, porque outros factores parecem ser mais importantes. Os resultados estão à vista. Todos nós já experimentamos uma nova versão de um produto que requer muito mais recursos que os seus predecessores.

Utilizando a Microsoft como exemplo, o Word 2.0 correrá facilmente num antigo 386 a 20 MHz. Claro que a versão mais recente faz muito mais, mas corre em hardware milhares de vezes mais potente, por isso é melhor que o faça.

Isto não é para implicar com a Microsoft, porque há inúmeros outros exemplos em que os ganhos de desempenho do hardware foram absorvidos por código e recursos mais exigentes. Habituámo-nos a isso, porque os programadores não tinham de se preocupar com os ciclos de desenvolvimento de CPU. Mas agora têm.  

O Spectre dá à indústria de desenvolvimento de software a oportunidade – e o imperativo – de mudar de rumo. Já não é suficiente confiar em processadores cada vez mais rápidos para absorver a expansão da programação.

Graças ao Spectre, o código eficiente tornou-se um argumento de venda, tanto para a Administração como para o mercado. Os bons programadores deverão conseguir compensar qualquer abrandamento relacionado com o Meltdown/Spectre e muito mais desde que lhes seja dado tempo e recursos para o fazer.

Com Alex Cruickshank




Deixe um comentário

O seu email não será publicado