Quão melhores são os compiladores Fortran realmente?

Esta pergunta é uma extensão de duas discussões que surgiram recentemente nas respostas a " C ++ vs Fortran for HPC ". E é um pouco mais um desafio do que uma pergunta ...

Um dos argumentos mais ouvidos em favor do Fortran é que os compiladores são apenas melhores. Como a maioria dos compiladores C / Fortran compartilham o mesmo back-end, o código gerado para programas semanticamente equivalentes nos dois idiomas deve ser idêntico. Pode-se argumentar, no entanto, que o C / Fortran é mais / menos fácil para o compilador otimizar.

Então decidi tentar um teste simples: peguei uma cópia do daxpy.f e doxpy.c e os compilei com gfortran / gcc.

Agora, o daxpy.c é apenas uma tradução f2c do daxpy.f (código gerado automaticamente, feio como o inferno), então peguei esse código e o limpei um pouco (conheça daxpy_c), o que basicamente significava reescrever o loop mais interno como

for ( i = 0 ; i < n ; i++ )
    dy[i] += da * dx[i];

Por fim, reescrevi (digite daxpy_cvec) usando a sintaxe de vetor do gcc:

#define vector(elcount, type)  __attribute__((vector_size((elcount)*sizeof(type)))) type
vector(2,double) va = { da , da }, *vx, *vy;

vx = (void *)dx; vy = (void *)dy;
for ( i = 0 ; i < (n/2 & ~1) ; i += 2 ) {
    vy[i] += va * vx[i];
    vy[i+1] += va * vx[i+1];
    }
for ( i = n & ~3 ; i < n ; i++ )
    dy[i] += da * dx[i];

Observe que eu uso vetores de comprimento 2 (isso é tudo o que o SSE2 permite) e que eu processo dois vetores por vez. Isso ocorre porque em muitas arquiteturas, podemos ter mais unidades de multiplicação do que elementos vetoriais.

Todos os códigos foram compilados usando o gfortran / gcc versão 4.5 com os sinalizadores "-O3 -Wall -msse2 -march = native -ffast-math -fomit-frame-ponteiro -malign-double -fstrict-aliasing". No meu laptop (CPU Intel Core i5, M560, 2,67GHz), obtive a seguinte saída:

pedro@laika:~/work/fvsc$ ./test 1000000 10000
timing 1000000 runs with a vector of length 10000.
daxpy_f took 8156.7 ms.
daxpy_f2c took 10568.1 ms.
daxpy_c took 7912.8 ms.
daxpy_cvec took 5670.8 ms.

Portanto, o código Fortran original leva um pouco mais de 8,1 segundos, a tradução automática leva 10,5 segundos, a ingênua implementação C faz isso em 7.9 e o código explicitamente vetorizado faz isso em 5.6, marginalmente menos.

Isso é Fortran sendo um pouco mais lento que a implementação C ingênua e 50% mais lento que a implementação C vetorizada.

Então, eis a questão: eu sou um programador C nativo e estou bastante confiante de que fiz um bom trabalho nesse código, mas o código Fortran foi tocado pela última vez em 1993 e, portanto, pode estar um pouco desatualizado. Como não me sinto tão confortável em codificar no Fortran quanto os outros aqui, alguém pode fazer um trabalho melhor, ou seja, mais competitivo em comparação com qualquer uma das duas versões C?

Além disso, alguém pode tentar este teste com icc / ifort? A sintaxe do vetor provavelmente não funcionará, mas eu ficaria curioso para ver como a versão C ingênua se comporta lá. O mesmo vale para qualquer pessoa com xlc / xlf por aí.

Fiz upload das fontes e de um Makefile aqui . Para obter tempos precisos, defina CPU_TPS em test.c com o número de Hz na sua CPU. Se você encontrar melhorias em qualquer uma das versões, poste-as aqui!

Atualizar:

Adicionei o código de teste do stali aos arquivos online e o completei com uma versão em C. Modifiquei os programas para fazer 1'000'000 loops em vetores de comprimento 10'000 para serem consistentes com o teste anterior (e porque minha máquina não pôde alocar vetores de comprimento 1'000'000'000, como no original de stali código). Como os números agora são um pouco menores, usei a opção -par-threshold:50para tornar o compilador mais propenso a paralelizar. A versão icc / ifort usada é 12.1.2 20111128 e os resultados são os seguintes

pedro@laika:~/work/fvsc$ OMP_NUM_THREADS=1 time ./icctest_c
3.27user 0.00system 0:03.27elapsed 99%CPU

pedro@laika:~/work/fvsc$ OMP_NUM_THREADS=1 time ./icctest_f
3.29user 0.00system 0:03.29elapsed 99%CPU

pedro@laika:~/work/fvsc$ OMP_NUM_THREADS=2 time ./icctest_c
4.89user 0.00system 0:02.60elapsed 188%CPU

pedro@laika:~/work/fvsc$ OMP_NUM_THREADS=2 time ./icctest_f
4.91user 0.00system 0:02.60elapsed 188%CPU

Em resumo, os resultados são, para todos os efeitos práticos, idênticos para as versões C e Fortran, e ambos os códigos são paralelos automaticamente. Observe que os tempos rápidos comparados ao teste anterior são devidos ao uso de aritmética de ponto flutuante de precisão única!

Atualizar:

Embora eu realmente não goste de onde está indo o ônus da prova aqui, recodifiquei o exemplo de multiplicação de matrizes de stali em C e o adicionei aos arquivos na web . Aqui estão os resultados do loop tripple para uma e duas CPUs:

pedro@laika:~/work/fvsc$ OMP_NUM_THREADS=1 time ./mm_test_f 2500
 triple do time   3.46421700000000     
3.63user 0.06system 0:03.70elapsed 99%CPU

pedro@laika:~/work/fvsc$ OMP_NUM_THREADS=1 time ./mm_test_c 2500
triple do time 3.431997791385768
3.58user 0.10system 0:03.69elapsed 99%CPU

pedro@laika:~/work/fvsc$ OMP_NUM_THREADS=2 time ./mm_test_f 2500
 triple do time   5.09631900000000     
5.26user 0.06system 0:02.81elapsed 189%CPU

pedro@laika:~/work/fvsc$ OMP_NUM_THREADS=2 time ./mm_test_c 2500
triple do time 2.298916975280899
4.78user 0.08system 0:02.62elapsed 184%CPU

Observe que, cpu_timeno Fortran, mede o tempo da CPU e não o tempo do relógio de parede, por isso encerrei as chamadas timepara compará-las para 2 CPUs. Não há diferença real entre os resultados, exceto que a versão C se sai um pouco melhor em dois núcleos.

Agora, para o matmulcomando, é claro apenas no Fortran, pois esse intrínseco não está disponível em C:

pedro@laika:~/work/fvsc$ OMP_NUM_THREADS=1 time ./mm_test_f 2500
 matmul    time   23.6494780000000     
23.80user 0.08system 0:23.91elapsed 99%CPU

pedro@laika:~/work/fvsc$ OMP_NUM_THREADS=2 time ./mm_test_f 2500
 matmul    time   26.6176640000000     
26.75user 0.10system 0:13.62elapsed 197%CPU

Uau. Isso é absolutamente terrível. Alguém pode descobrir o que estou fazendo de errado ou explicar por que esse intrínseco ainda é de alguma forma uma coisa boa?

Não adicionei as dgemmchamadas ao benchmark, pois são chamadas de biblioteca para a mesma função no Intel MKL.

Para testes futuros, alguém pode sugerir um exemplo conhecido por ser mais lento em C do que em Fortran?

Atualizar

Para verificar a afirmação de stali de que o matmulintrínseco é "uma ordem de grandeza" mais rápido que o produto de matriz explícita em matrizes menores, modifiquei seu próprio código para multiplicar matrizes de tamanho 100x100 usando os dois métodos, 10.000 vezes cada. Os resultados, em uma e duas CPUs, são os seguintes:

pedro@laika:~/work/fvsc$ OMP_NUM_THREADS=1 time ./mm_test_f 10000 100
 matmul    time   3.61222500000000     
 triple do time   3.54022200000000     
7.15user 0.00system 0:07.16elapsed 99%CPU

pedro@laika:~/work/fvsc$ OMP_NUM_THREADS=2 time ./mm_test_f 10000 100
 matmul    time   4.54428400000000     
 triple do time   4.31626900000000     
8.86user 0.00system 0:04.60elapsed 192%CPU

Atualizar

O Grisu está correto ao apontar que, sem otimizações, o gcc converte operações em números complexos em chamadas de função de biblioteca, enquanto o gfortran as alinha em algumas instruções.

O compilador C gerará o mesmo código compacto se a opção -fcx-limited-rangeestiver configurada, ou seja, o compilador é instruído a ignorar o excesso / subfluxo potencial nos valores intermediários. Esta opção é de alguma forma definida por padrão no gfortran e pode levar a resultados incorretos. Forçar o -fno-cx-limited-rangegfortran não mudou nada.

Portanto, esse é realmente um argumento contra o uso de gfortran para cálculos numéricos: operações em valores complexos podem exceder ou estourar mesmo que os resultados corretos estejam dentro do intervalo de ponto flutuante. Este é realmente um padrão Fortran. No gcc ou no C99 em geral, o padrão é fazer as coisas estritamente (leia IEEE-754), a menos que especificado de outra forma.

Lembrete: Lembre-se de que a principal questão era se os compiladores Fortran produzem código melhor que os compiladores C. Este não é o lugar para discussões quanto aos méritos gerais de um idioma em detrimento de outro. O que eu realmente estaria interessado é se alguém puder encontrar uma maneira de convencer o gfortran a produzir um daxpy tão eficiente quanto o do C usando vetorização explícita, pois isso exemplifica os problemas de ter que confiar no compilador exclusivamente para otimização do SIMD ou um caso em que um compilador Fortran supera sua contraparte C.

A diferença nos tempos parece ser devida ao desenrolamento manual do Fortran daxpy . Os seguintes tempos estão em um Xeon X5650 de 2,67 GHz, usando o comando

./test 1000000 10000

Compiladores Intel 11.1

Fortran com desenrolamento manual: 8,7 seg
Fortran sem desenrolamento manual: 5,8 seg
C sem desenrolamento manual: 5,8 seg

Compiladores GNU 4.1.2

Fortran com desenrolamento manual: 8,3 seg
Fortran sem desenrolamento manual: 13,5 seg
C sem desenrolamento manual: 13,6 seg
C com atributos vetoriais: 5,8 seg

Compiladores GNU 4.4.5

Fortran com desenrolamento manual: 8,1 seg
Fortran sem desenrolamento manual: 7,4 seg
C sem desenrolamento manual: 8,5 seg
C com atributos vetoriais: 5,8 seg

Conclusões

• O desenrolar manual ajudou os compiladores GNU 4.1.2 Fortran nessa arquitetura, mas prejudica a versão mais recente (4.4.5) e o compilador Intel Fortran.
• O compilador GNU 4.4.5 C é muito mais competitivo com o Fortran do que na versão 4.2.1.
• As intrínsecas vetoriais permitem que o desempenho do GCC corresponda aos compiladores da Intel.

Hora de testar rotinas mais complicadas, como dgemv e dgemm?

Estou chegando atrasado para esta festa, por isso é difícil para mim acompanhar o que vem de cima. A questão é grande, e acho que se você estiver interessado, pode ser dividido em pedaços menores. Uma coisa que me interessou foi simplesmente o desempenho de suas daxpyvariantes e se o Fortran é mais lento que C nesse código muito simples.

Executando o meu laptop (Macbook Pro, Intel Core i7, 2,66 GHz), o desempenho relativo da versão C vetorizada à mão e da versão Fortran vetorizada não à mão depende do compilador usado (com suas próprias opções):

Compiler     Fortran time     C time
GCC 4.6.1    5408.5 ms        5424.0 ms
GCC 4.5.3    7889.2 ms        5532.3 ms
GCC 4.4.6    7735.2 ms        5468.7 ms

Portanto, parece que o GCC ficou melhor em vetorizar o loop no ramo 4.6 do que era antes.

No debate geral, acho que é possível escrever código rápido e otimizado no C e no Fortran, quase como na linguagem assembly. Vou apontar, no entanto, uma coisa: assim como o assembler é mais tedioso para escrever do que C, mas oferece um controle mais refinado sobre o que é executado pela CPU, C é de nível mais baixo que o Fortran. Assim, oferece mais controle sobre os detalhes, o que pode ajudar a otimizar, onde a sintaxe padrão do Fortran (ou suas extensões de fornecedor) pode não ter funcionalidade. Um caso é o uso explícito de tipos de vetores, outro é a possibilidade de especificar o alinhamento de variáveis ​​manualmente, algo que o Fortran é incapaz.

A maneira como eu escreveria o AXPY no Fortran é um pouco diferente. É a tradução exata da matemática.

m_blas.f90

 module blas

   interface axpy
     module procedure saxpy,daxpy
   end interface

 contains

   subroutine daxpy(x,y,a)
     implicit none
     real(8) :: x(:),y(:),a
     y=a*x+y
   end subroutine daxpy

   subroutine saxpy(x,y,a)
     implicit none
     real(4) :: x(:),y(:),a
     y=a*x+y
   end subroutine saxpy

 end module blas

Agora vamos chamar a rotina acima em um programa.

test.f90

 program main

   use blas
   implicit none

   real(4), allocatable :: x(:),y(:)
   real(4) :: a
   integer :: n

   n=1000000000
   allocate(x(n),y(n))
   x=1.0
   y=2.0
   a=5.0
   call axpy(x,y,a)
   deallocate(x,y)

 end program main

Agora vamos compilar e executá-lo ...

login1$ ifort -fast -parallel m_blas.f90 test.f90
ipo: remark #11000: performing multi-file optimizations
ipo: remark #11005: generating object file /tmp/ipo_iforttdqZSA.o

login1$ export OMP_NUM_THREADS=1
login1$ time ./a.out 
real    0 m 4.697 s
user    0 m 1.972 s
sys     0 m 2.548 s

login1$ export OMP_NUM_THREADS=2
login1$ time ./a.out 
real    0 m 2.657 s
user    0 m 2.060 s
sys     0 m 2.744 s

Observe que não estou usando nenhum loop ou nenhuma diretiva explícita do OpenMP . Isso seria possível em C (ou seja, sem uso de loops e paralelismo automático)? Eu não uso C, então não sei.

Eu acho que não é apenas interessante como um compilador otimiza o código para o hardware moderno. Especialmente entre o GNU C e o GNU Fortran, a geração de código pode ser muito diferente.

Então, vamos considerar outro exemplo para mostrar as diferenças entre eles.

Usando números complexos, o compilador GNU C produz uma grande sobrecarga para operações aritméticas quase muito básicas em um número complexo. O compilador Fortran fornece um código muito melhor. Vamos dar uma olhada no pequeno exemplo a seguir no Fortran:

COMPLEX*16 A,B,C
C=A*B

dá (gfortran -g -o complex.fo -c complex.f95; objdump -d -S complex.fo):

C=A*B
  52:   dd 45 e0                fldl   -0x20(%ebp)
  55:   dd 45 e8                fldl   -0x18(%ebp)
  58:   dd 45 d0                fldl   -0x30(%ebp)
  5b:   dd 45 d8                fldl   -0x28(%ebp)
  5e:   d9 c3                   fld    %st(3)
  60:   d8 ca                   fmul   %st(2),%st
  62:   d9 c3                   fld    %st(3)
  64:   d8 ca                   fmul   %st(2),%st
  66:   d9 ca                   fxch   %st(2)
  68:   de cd                   fmulp  %st,%st(5)
  6a:   d9 ca                   fxch   %st(2)
  6c:   de cb                   fmulp  %st,%st(3)
  6e:   de e9                   fsubrp %st,%st(1)
  70:   d9 c9                   fxch   %st(1)
  72:   de c2                   faddp  %st,%st(2)
  74:   dd 5d c0                fstpl  -0x40(%ebp)
  77:   dd 5d c8                fstpl  -0x38(%ebp)

Que são códigos de máquina de 39 bytes. Quando consideramos o mesmo em C

 double complex a,b,c; 
 c=a*b; 

e dê uma olhada na saída (feita da mesma maneira como acima), obtemos:

  41:   8d 45 b8                lea    -0x48(%ebp),%eax
  44:   dd 5c 24 1c             fstpl  0x1c(%esp)
  48:   dd 5c 24 14             fstpl  0x14(%esp)
  4c:   dd 5c 24 0c             fstpl  0xc(%esp)
  50:   dd 5c 24 04             fstpl  0x4(%esp)
  54:   89 04 24                mov    %eax,(%esp)
  57:   e8 fc ff ff ff          call   58 <main+0x58>
  5c:   83 ec 04                sub    $0x4,%esp
  5f:   dd 45 b8                fldl   -0x48(%ebp)
  62:   dd 5d c8                fstpl  -0x38(%ebp)
  65:   dd 45 c0                fldl   -0x40(%ebp)
  68:   dd 5d d0                fstpl  -0x30(%ebp)

Também são códigos de máquina de 39 bytes, mas a função 57 menciona a etapa, faz a parte apropriada do trabalho e executa a operação desejada. Portanto, temos um código de máquina de 27 bytes para executar a operação múltipla. A função por trás do muldc3 é fornecida por libgcc_s.soe possui uma área útil de 1375 bytes no código da máquina. Isso diminui drasticamente o código e fornece uma saída interessante ao usar um criador de perfil.

Quando implementamos os exemplos BLAS acima para zaxpye realizamos o mesmo teste, o compilador Fortran deve fornecer melhores resultados que o compilador C.

(Usei o GCC 4.4.3 para este experimento, mas notei esse comportamento para o qual outro GCC é lançado.)

Então, na minha opinião, não pensamos apenas em paralelização e vetorização quando pensamos em qual é o melhor compilador, também temos que ver como as coisas básicas são traduzidas para o código do assembler. Se essa tradução der código incorreto, a otimização poderá usar essas coisas apenas como entrada.

Pessoal,

Achei essa discussão muito interessante, mas fiquei surpreso ao ver que reordenar os loops no exemplo de Matmul mudou a imagem. Como não tenho um compilador Intel disponível na minha máquina atual, estou usando o gfortran, mas reescrevendo os loops no mm_test.f90 para

call cpu_time(start)  
do r=1,runs  
  mat_c=0.0d0  
     do j=1,n  
        do k=1,n  
  do i=1,n  
           mat_c(i,j)=mat_c(i,j)+mat_a(i,k)*mat_b(k,j)  
        end do  
     end do  
  end do  
end do  
call cpu_time(finish)  

alterei todos os resultados para minha máquina.

Os resultados de temporização da versão anterior foram:

#time ./mm_test_f 10000 100
 matmul    time   6.3620000000000001     
 triple do time   21.420999999999999     

considerando que, com os laços triplos reorganizados como indicado acima:

#time ./mm_test_f 10000 100
 matmul    time   6.3929999999999998     
 triple do time   3.9190000000000005    

Este é o gcc / gfortran 4.7.2 20121109 em uma CPU Intel (R) Core (TM) i7-2600K a 3.40GHz

Os sinalizadores do compilador usados ​​foram os do Makefile que cheguei aqui ...

Não são as linguagens que tornam o código mais rápido, embora ajudem. É o compilador, a CPU e o sistema operacional que torna os códigos executados mais rapidamente. Comparar idiomas é apenas um nome impróprio, inútil e sem sentido. Não faz nenhum sentido, porque você está comparando duas variáveis: a linguagem e o compilador. Se um código for mais rápido, você não sabe quanto é a linguagem ou quanto é o compilador. Eu não entendo por que a comunidade de ciência da computação simplesmente não entende isso :-(