Para testar um loop distribuído, resolvi criar uma função que calcula a multiplicação entre duas matrizes, colocando o resultado em uma terceira matriz (MC = MA * MB):

const int MATRIX_SIZE = 1000;

int MA[MATRIX_SIZE][MATRIX_SIZE];
int MB[MATRIX_SIZE][MATRIX_SIZE];
int MC[MATRIX_SIZE][MATRIX_SIZE];

void multi()
{
    int soma;

    //percorre cada linha de MA
    for(int j = 0; j < MATRIX_SIZE; j++)
    {
        //percorre cada coluna de MB
        for(int i = 0; i < MATRIX_SIZE; i++, soma = 0)
        {
            //calcula
            for(int k = 0; k < MATRIX_SIZE; k++)
            {
                soma += MA[j][k] * MB[k][i];
            }

            //coloca resoltado na matriz MC
            MC[j][i] = soma;
        }
    }
}

int main(int ac, char **av)
{
    multi();
    return 0;
}

Como o teste consiste em melhorar o desempenho do cálculo, não me dei ao trabalho de iniciar os elementos das matrizes e nem de verificar se o resultado está correto.

Executando o código anterior, o Code::Blocks retornou a mensagem:

Process returned 0 (0×0)   execution time : 23.509 s
Press any key to continue.

Lembrando que executei a compilação debug sem nenhum tipo de otimização. Com certeza a release seria muito mais rápida.

Quem lembra das aulas de matemática do colegial, sabe que o cálculo de cada elemento resultante (MC) independe do cálculo de elementos anteriores. O laço for está de acordo com as restrições impostas pela API, então, pq não dividir a tarefa em várias threads?

const int MATRIX_SIZE = 1000;

int MA[MATRIX_SIZE][MATRIX_SIZE];
int MB[MATRIX_SIZE][MATRIX_SIZE];
int MC[MATRIX_SIZE][MATRIX_SIZE];

void multi()
{
    //percorre cada linha de MA
    #pragma omp parallel for
    for(int j = 0; j < MATRIX_SIZE; j++)
    {
        //percorre cada coluna de MB
        for(int i = 0; i < MATRIX_SIZE; i++)
        {
            int soma = 0;

            //calcula
            for(int k = 0; k < MATRIX_SIZE; k++)
            {
                soma += MA[j][k] * MB[k][i];
            }

            //coloca resoltado na matriz MC
            MC[j][i] = soma;
        }
    }
}

int main(int ac, char **av)
{
    multi();
    return 0;
}

Repare que, além do #pragma omp parallel for adicionado antes do primeiro loop, outras mudanças foram feitas para adaptar o código:

• A variável soma foi removida do começo da função e declarada dentro do segundo for, para evitar que seja compartilhada entre as threads;
• Não é mais necessário zerar a variável soma no corpo do segundo for;

Executando o código modificado, obtive o seguinte resultado:

Process returned 0 (0×0)   execution time : 7.129 s
Press any key to continue.

Isso corresponde a, praticamente, um terço do tempo necessário para calcular pelo método tradicional. Surpreso? Requisitando 20 threads para executar o loop, obtive um resultado melhor ainda:

Process returned 0 (0×0)   execution time : 6.692 s
Press any key to continue.

Okay, a diferença não é gritante, mas num sistema onde o desempenho é um faor crítico, esses ms podem fazer toda a diferença.

Agora que vc já conseguiu compilar o “Hello World” do primeiro post, vamos fazer bom uso do processamento distribuído nos nossos laços da repetição.

Primeiramente, vc deve entender que, na programação com OpenMP, temos variáveis (parte da memória) compartilhadas e privates.

Quê?!

No exemplo abaixo, a variável a é visível para todas as threads que executarão a tarefa do bloco. Já a variável b possui uma cópia exclusiva em cada thread, ou seja, cada thread possui sua variável b.

void some_function()
{
    int a = 0;

    #pragma omp parallel
    {
        int b = 1;
    }
}

Okay, entendi… e daí?

Por enquanto, leve em conta que saber disso pode evitar várias dores de cabeça.

Usando OpenMP nos laços de repetição

Para tal operação, definimos a seguinte linha antes do nosso for:

#pragma omp parallel for

Ficando assim:

#pragma omp parallel for
for(int i = 0; i < 10; i++)
{
    printf("iteration %d on thread %d\n", i, omp_get_thread_num());
}

O resultado é:

Nesse exemplo, as iterações do for serão divididas em várias threads (na minha execução, 3 threads). O número de threads corresponde ao número padrão ou o valor que vc definiu com omp_set_num_threads(num_threads). Para não ter o trabalho de chamar a função em cada parte do código que vc deseja alterar o número de threads, a seguinte sintaxe é permitida:

#pragma omp parallel for num_threads(NUM_THREADS)

Onde NUM_THREADS corresponde ao número de threads que devem executar a tarefa.

Se o exemplo anterior for modificado para:

#pragma omp parallel for num_threads(2)
for(int i = 0; i < 10; i++)
{
    printf("iteration %d on thread %d\n", i, omp_get_thread_num());
}

Então o loop vai ser dividido em, no máximo, duas threads como mostra o resultado:

Como podemos notar, apenas as threads de ID 0 e 1 executam o for.

Repare que as iterações não são executadas em ordem, então leve em conta que se uma iteração depende de outra, como na soma de médias num vetor de alunos, por exemplo (existe um jeito de fazer isso, vou explicar mais pra frente), vc terá problemas.

A API OpenMP impõe  as seguintes restrições no uso de loops paralelos:

1. A variável que controla o loop (no caso anterior, i) deve ser do tipo signed integer;
2. A operação de comparação no corpo for deve ser do tipo loop_variable <, <=, >, >= integer_invariável;
3. A terceira expressão do corpo for deve ser do tipo que incrementa (x++) ou decrementa (x- -);
4. Se a operação de comparação usar os operadores < ou <=, então a variável de controle deve ser incrementada a cada iteração. No caso contrário, se forem utilizados os operadores > ou >=, então a variável de controle deve ser decrementada a cada iteração;
5. O loop deve consistir em um único bloco de código, sem jumps (goto, por exemplo) para fora do loop. Como exceção, podemos usar exit() que finaliza a aplicação e não apenas a thread em questão. Caso vc utilize um break ou goto, esses devem levar a algum lugar DENTRO do loop e não fora. O mesmo vale para exceptions, que devem ser tratadas dentro do loop e não fora dele;

Para deixar mais claro aquele conceito de memória compartilhada e private, temos o exemplo abaixo que não é válido, pois a variável temp é compartilhada por todas as threads, ou seja, enquanto a thread de ID 0 escreve um valor X e espera ler esse valor algumas instruções adiante, a thread de ID 1 escreve um valor Y no mesmo endereço de memória:

int a[4] = {1, 2, 4, 8};
int temp;

#pragma omp parallel for
for(int i = 0; i < 4; i++)
{
    temp = a[i];
}

Para um resultado correto, o ideal seria declarar a variável temp dentro do laço for:

int a[4] = {1, 2, 4, 8};

#pragma omp parallel for
for(int i = 0; i < 4; i++)
{
    int temp;
    temp = a[i];
}

Reductions

Nos permite compartilhar uma variável sem que sua integridade seja comprometida pela concorrência entre threads. Veja o exemplo:

int notas[10] = {7, 4, 8, 3, 6, 9, 10, 1, 2, 5};
int soma = 0;

#pragma omp parallel for
for(int i = 0; i < 10; i++)
{
    soma += notas[i];
}

printf("soma = %d\n", soma);

Não podemos garantir que a soma seja 55, pois todas as threads estão usando a mesma variável. Criar um lock? Não é necessário, pois a API nos permite fazer da seguinte forma:

int notas[10] = {7, 4, 8, 3, 6, 9, 10, 1, 2, 5};
int soma = 0;

#pragma omp parallel for reduction(+:soma)
for(int i = 0; i < 10; i++)
{
    soma += notas[i];
}

printf("soma = %d\n", soma);

Nos bastidores, o OpenMP cria uma variável private soma para cada thread e, ao final, soma todas e coloca o valor na variável compartilhada (global) soma. Então vc pode ter certeza que o valor de soma é o esperado.

As outras operações disponíveis são:

• + (adição): a variável private inicia com o valor 0;
• - (subtração): a variável private inicia com o valor 0;
• * (multiplicação): a variável private inicia com o valor 1;
• & (operador AND): a variável private inicia com o valor ~0;
• | (operador OR): a variável private inicia com o valor 0;
• ^ (operador OR exclusivo): a variável private inicia com o valor 0;
• && (operador condicional AND): a variável private inicia com o valor 1;
• || (operador condicional OR): a variável private inicia com o valor 0;

A segunda parte eu deixo para outro post

Hoje em dia é normal ouvir do vendedor “Esse computador é ótimo! Tem 4 GB de RAM e é um Core Duo!“. Apesar de, na maioria das vezes, a pessoa nem fazer idéia do que diabos é um Core Duo. Mas tudo bem, esse é o papel do vendedor, certo? É claro que qualquer entendido sabe que isso não qualifica o produto como “bom“, longe disso, temos que levar em conta muitos outros detalhes que pessoas que não são da área não entendem.

Com a chegada dos processadores de múltiplos núcleos, o marketing direcionou-se à  esse fator e esqueceu de que memória cache e barramento contam MUITO no desempenho. A maioria das pessoas não entendem, por exemplo, que um processador de 2 núcleos de 2.0 GHz NÃO significa 4.0 GHz ou que um sistema operacional de 32 bits não aproveita as vantagens do hardware de 64 bits.

O que me deixa triste é ouvir esse tipo de  enganação picaretagem de amigos/conhecidos da faculdade ( Tecnologia em Informática com Ênfase em Gestão de Negócios – FATEC Rio Preto). By the way, não quero desmerecer a faculdade, pois devo muito à vários professores que tiveram a paciência de aguentar alunos como eu e o bomba.

Antes de entrar no assunto principal, entenda que não adianta ter um processador com 487564764 núcleos se o software não sabe como utilizá-los, okay?

Como recentemente adquiri um Phenom X3 (é, 3 núcleos) resolvi descobrir como aproveitar todo esse poder. Com uma busca aqui e uma ali (no oráculo), trago o que aprendi.

OpenMP?

O OpenMP (Open Multi-Processing) é uma API aberta para programação paralela. De acordo com o site oficial:

A API OpenMP auxilia na programação multiplataforma, paralela e com memória compartilhada em C/C++ e Fortran em todas as arquiteturas, incluindo plataformas Unix e Windows NT. Constituída por um grupo de grandes empresas de hardware e software, o OpenMP é um modelo portável e escalável que oferece ao programador uma interface flexível para o desenvolvimento de aplicações paralelas visando desktop até supercomputadores.

A tradução no olhômetro ficou um lixo, mas dá pra ter uma idéia do que se trata.

Beleza, nunca ouvi falar. Vale a pena alocar recursos (tempo) para aprender?

Saiba que essa API (pelo menos a especificação) existe desde 1997, sendo os membros permanentes do Architecture Review Board (ARB):

• AMD (David Leibs)
• Cray (James Beyer)
• Fujitsu (Matthijs van Waveren)
• HP (Uriel Schafer)
• IBM (Kelvin Li)
• Intel (Sanjiv Shah)
• NEC (Kazuhiro Kusano)
• The Portland Group, Inc. (Michael Wolfe)
• SGI (Lori Gilbert)
• Sun Microsystems (Nawal Copty)
• Microsoft (-)

(Retirado do site oficial)

Convencido(a)?

Instalando o OpenMP

É simples, você não instala.

Como assim?

Você DEVE ter um compilador que tenha o OpenMP implementado.

E o meu compilador implementa?

Aqui vc pode ver a lista de compiladores que disponibilizam o recurso. Como, provavelmente, vc usa:

• Visual C++ 2008: apenas a versão Professional (ou sei lá o nome da versão que não seja a Express) possui os headers necessários. ACHO que se vc copiar os headers da versão paga para a Express, irá funcionar;
• Code::Blocks (MinGW): apenas nas versões (do gcc) 4.3.2 ou superiores.

Baixei o MinGW mais recente no site oficial e instalei para usar com o Code::Blocks. Porém, a versão do gcc era a 3.4.alguma-coisa e é claro, não funcionou pois não possuia os headers necessários.

Então, resolvi instalar logo o TDM’s GCC/MinGW que é uma build não oficial dos binários mais recentes do GCC. Faça o download do instalador mais recente e, na hora da instalação, escolha o diretório MinGW que está dentro do diretório de instalação do seu Code::Blocks (no meu caso, E:\CodeBlocks\MinGW):

Clique em “Next >” e selecione um mirror:

Clique em “Next >” e selecione apenas os componentes que deseja instalar. No meu caso, deixei como está (todos):

Após selecionar os componentes, clique em “Install” e espere a extração dos arquivos terminar.

Hello World!

Se tudo estiver certo, então será possível compilar o “Hello World” abaixo:

#include <omp.h>
#include <stdio.h>

int main()
{
#pragma omp parallel
printf("Hello! (from thread %d, num. threads %d)\n",
omp_get_thread_num(),
omp_get_num_threads());
}

Antes de tentar rodar o exemplo, precisamos definir a compile-time flag -fopenmp para que o compilador saiba que o projeto utiliza o OpenMP. Se vc compilar pelo prompt de comando diretamente com o GCC, basta adicionar o parâmetro -fopenmp, ficando assim:

gcc.exe hello_world.c -o hello_world.exe -fopenmp

Já no Code::Blocks, vc também precisa linkar a libgomp.dll.a e ter o arquivo libgomp-1.dll na pasta BIN do seu compilador ou na pasta do seu projeto. Então, faça assim:

• Selecione a opção “Build options…” no menu “Project” do Code::Blocks;
• Na lista da esquerda, selecione o seu projeto (o 1º item, não o Debug, nem o Release);
• Procure a aba “Other options” dentro da aba “Compiler settings”. Adicione a flag -fopenmp;
  
• Agora selecione a aba “Linker settings” e adicione o arquivo libgomp.dll.a. Na minha instalação, esse arquivo estava no diretório “E:\CodeBlocks\MinGW\lib\gcc\mingw32\4.4.1\“;
• É importante que vc linke o arquivo libgomp.dll.a e não o libgomp.a;
• O projeto já pode ser compilado, mas para que funcione, será necessário copiar o arquivo libgomp-1.dll para o diretório do seu executável. Assim como a lib, o diretório em que esse arquivo pode ser encontrado não é tão trivial. Na minha instalação, encontrei em “E:\CodeBlocks\MinGW\lib\gcc\mingw32\bin“;
• Creio que não é necessário explicar a parte de copiar o arquivo (CTRL + C, CTRL + V, a mesma coisa que vc usa para fazer os trabalhos da faculdade).

Btw, GOMP é o projeto que implementou o OpenMP nos compiladores C, C++ e Fortran do GNU Compiler Collection.

Pronto, o Hello World deve (ou deveria) mostrar algumas mensagens “Hello!” com o ID da thread em que está sendo executado, seguido do número de threads. Aqui tive o seguinte resultado:

Mas por que 3 threads? Porque esse é o número padrão para a variável ambiente OMP_NUM_THREADS (na minha implementação, pelo menos). Para definir o número de threads, chame a função omp_set_num_threads(num_threads). Então, o “Hello World” modificado ficaria assim:

#include <omp.h>
 #include <stdio.h>

 int main()
 {
 omp_set_num_threads(10);

 #pragma omp parallel
 printf("Hello! (from thread %d, num. threads %d)\n",
 omp_get_thread_num(),
 omp_get_num_threads());
 }

Agora vc verá 10 mensagens “Hello!”.

É só isso?

Não. Apesar de simples, o exemplo anterior usa eficientemente todos os núcleos disponíveis, de forma transparente. Pode parecer que não houve um grande ganho no desempenho, mas com alguns testes vamos ver que a programação multicore pode otimizar de forma significativa o aplicativo.

Para que o post não fique cansativo, deixo o resto para semana que vem.

Fonte: OpenMP.org