Quando devo usar modelos de expressão C ++ na ciência da computação e quando * não * devo usá-los?

Suponha que eu esteja trabalhando em um código científico em C ++. Em uma discussão recente com um colega, foi argumentado que os modelos de expressão poderiam ser uma coisa muito ruim, potencialmente tornando o software compilável apenas em determinadas versões do gcc. Supostamente, esse problema afetou alguns códigos científicos, como aludido nas legendas dessa paródia de Downfall . (Estes são os únicos exemplos que conheço, daí o link.)

No entanto, outras pessoas argumentaram que os modelos de expressão são úteis porque podem gerar ganhos de desempenho, como neste artigo no SIAM Journal of Scientific Computing , evitando o armazenamento de resultados intermediários em variáveis ​​temporárias.

Não sei muito sobre metaprogramação de modelos em C ++, mas sei que é uma abordagem usada na diferenciação automática e na aritmética de intervalos. Foi assim que entrei em uma discussão sobre modelos de expressão. Dadas as vantagens em potencial no desempenho e as desvantagens em manutenção (se essa é a palavra certa), quando devo usar os modelos de expressão C ++ na ciência da computação e quando devo evitá-los?

Meu problema com os modelos de expressão é que eles são uma abstração muito vazada. Você gasta muito trabalho escrevendo código muito complicado para executar uma tarefa simples com uma sintaxe melhor. Porém, se você deseja alterar o algoritmo, precisa mexer no código sujo e, se usar tipos ou sintaxe, recebe mensagens de erro completamente ininteligíveis. Se o seu aplicativo é mapeado perfeitamente para uma biblioteca baseada em modelos de expressão, pode valer a pena considerar, mas se você não tiver certeza, eu recomendaria apenas escrever o código normal. Claro, o código de alto nível é menos bonito, mas você pode fazer o que precisa ser feito. Como benefício, o tempo de compilação e os tamanhos binários diminuirão muito e você não precisará lidar com uma enorme variação no desempenho devido à escolha do compilador e do sinalizador de compilação.

Outros comentaram sobre a dificuldade de escrever programas de ET, bem como a complexidade de entender as mensagens de erro. Deixe-me comentar sobre a questão dos compiladores: É verdade que, um tempo atrás, um dos grandes problemas foi encontrar um compilador compatível o suficiente com o padrão C ++ para fazer tudo funcionar e funcionar de maneira portável. Como conseqüência, encontramos muitos bugs - eu tenho 2-300 relatórios de bugs em meu nome, distribuídos por gcc, Intel icc, IBM xlC e pgicc de Portland. Consequentemente, o script de configuração deal.II é um repositório de um grande número de testes de erros do compilador, principalmente na área de modelos, declarações de amigos, espaços para nome, etc.

Mas acontece que os fabricantes do compilador realmente se uniram: hoje, o gcc e o icc passam em todos os nossos testes e é fácil escrever um código portátil entre os dois. Eu diria que a IGP não está muito atrasada, mas tem uma série de peculiaridades que parecem não desaparecer ao longo dos anos. O xlC, por outro lado, é uma história totalmente diferente - eles corrigem um bug a cada 6 meses, mas, apesar de apresentarem relatórios de bug durante anos, o progresso é extremamente lento e o xlC nunca conseguiu compilar o acordo.

O que tudo isso significa é o seguinte: se você se mantém com os dois grandes compiladores, pode esperar que eles funcionem hoje. Como a maioria dos computadores e sistemas operacionais hoje em dia normalmente possui pelo menos um deles, isso é suficiente. A única plataforma onde as coisas são mais difíceis é o BlueGene, onde o compilador do sistema geralmente é o xlC, com todos os seus bugs.

Eu experimentei um pouco com ETs há muito tempo, quando, como você mencionou, os compiladores ainda estavam lutando com eles. Eu usei a biblioteca blitz para álgebra linear em algum código meu. O problema foi obter o bom compilador e, como eu não sou um programador C ++ perfeito, interpretar as mensagens de erro do compilador. O último era simplesmente incontrolável. O compilador geraria, em média, cerca de 1000 linhas de mensagens de erro. De maneira alguma eu fui capaz de encontrar rapidamente meu erro de programação.

Você pode encontrar mais informações na página da on- line (existem os procedimentos de duas oficinas de ET).

Mas eu ficaria longe deles ....

O problema já começa com o termo 'modelos de expressão (ET)'. Não sei se existe uma definição precisa para isso. Mas em seu uso comum, de alguma forma, combina 'como você codifica expressões de álgebra linear' e 'como ele é computado'. Por exemplo:

Você codifica a operação vetorial

v = 2*x + 3*y + 4*z;                    // (1)

E é calculado por um loop

for (int i=0; i<n; ++i)                 // (2)
    v(i) = 2*x(i) + 3*y(i) + 4*z(i);

Na minha opinião, são duas coisas diferentes e precisam ser dissociadas: (1) é uma interface e (2) uma implementação possível. Quero dizer, isso é uma prática comum em programação. Certamente (2) pode ser uma boa implementação padrão, mas em geral eu quero poder utilizar uma implementação especializada e dedicada. Por exemplo, eu quero que uma função como

myGreatVecSum(alpha, x, beta, y, gamma, z, result);    // (3)

ser chamado quando estou codificando (1). Talvez (3) apenas use internamente um loop como em (2). Mas, dependendo do tamanho do vetor, outras implementações podem ser mais eficientes. De qualquer forma, algum especialista em alto desempenho pode implementar e ajustar (3) o máximo possível. Portanto, se (1) não pode ser mapeado para uma chamada de (3), evito o açúcar sintático de (1) e chamo diretamente (3) imediatamente.

O que eu descrevo não é novidade. Pelo contrário, é a ideia por trás do BLAS / LPACK:

• Todas as operações críticas de desempenho no LAPACK são feitas chamando as funções BLAS.
• O BLAS apenas define uma interface para as expressões de álgebra linear que são comumente necessárias.
• Para o BLAS, existem diferentes implementações otimizadas.

Se o escopo do BLAS não for suficiente (por exemplo, ele não fornece uma função como (3)), pode-se estender o escopo do BLAS. Portanto, este dinossauro dos anos 60 e 70 percebe, com sua ferramenta da idade da pedra, uma separação limpa e ortogonal da interface e implementação. É engraçado que (a maioria) das bibliotecas numéricas C ++ não atinjam esse nível de qualidade de software. Embora a própria linguagem de programação seja muito mais sofisticada. Portanto, não é de surpreender que o BLAS / LAPACK ainda esteja vivo e se desenvolva ativamente.

Então, na minha opinião, os ETs não são maus por si só. Mas como eles são comumente usados ​​em bibliotecas numéricas C ++ ganharam uma reputação muito ruim nos círculos científicos da computação.