OpenMP

[power]

Boa noite

Algum dos ide's gratis dá para usar openMP?

Cumprimentos

Power

[Rui Carlos]

IDE?

O que precisas é de um compilador com suporte para OpenMP.

[power]

compiladores livres para windows?

IDE?

O que precisas é de um compilador com suporte para OpenMP.

[Rui Carlos]

Nunca programei C/C++ em windows...

Não sei se já viste aqui: http://openmp.org/wp/openmp-compilers/

Na lista está o Visual Studio. Penso que há uma versão gratuita do mesmo.

[fnds]

Na lista está o Visual Studio. Penso que há uma versão gratuita do mesmo.

Há, mas é limitada, http://www.microsoft.com/Express/.

[Marfig]

Penso que o Visual Studio só suporta OpenMP a partir da versão professional. O Express não.

O GCC suporta OpenMP. O port para windows MinGW será neste caso a melhor opção. No entanto, pessoalmente sugiro que se não existir uma razão concreta para se usar o OpenMP, que se opte em vez disso por pthreads ou, melhor ainda, Boost::threads.

Em relação ao editor, qualquer um que suporte MinGW no windows serve. Sugiro Code:Blocks como um bom editor free.

[power]

Bom dia

Estive as ver as  opções do GCC 3.4.5 release for MinGW

e não tem suporte para openMP

Cumprimentos

Power

[Rui Carlos]

No entanto, pessoalmente sugiro que se não existir uma razão concreta para se usar o OpenMP, que se opte em vez disso por pthreads ou, melhor ainda, Boost::threads.

Eu pessoalmente sugiro o contrário 😄 Se o OpenMP for suficiente, aconselho a sua utilização. É uma solução simples, não só para quem escreve o código, mas também para quem tiver que interpretar a paralelização que foi feita, e permite adicionar e remover a paralelização facilmente.

Estive as ver as  opções do GCC 3.4.5 release for MinGW

e não tem suporte para openMP

As versões mais recentes (4.x) já deviam suportar. Não podes usar estas?

EDIT: vê se isto serve - http://www.cs.uoi.gr/~ompi/

[Triton]

Experimenta esta versão: http://nuwen.net/mingw.html

[power]

Bom dia

quero agradecer a todos pelas vossas dicas e ajudas  😛

Experimenta esta versão: http://nuwen.net/mingw.html

Estive a ler e parece-me que não tem esta funcionalidade!!

Porque é que eu preciso muito de ajuda

1º - não sou programador, alias quando andava na escola odiava programação (Pascal e c)

2º - Agora preciso tive de aprender por mim proprio os rudimentos.

3º -  O programa que já está feito em visual basic mas só que eu preciso que o programa faça muitos ciclos for, while, if etc.... +/- 5milhões

4º - Como li que o openmp consegue por os 2 cpu's a funcionar em simultaneo (amd dual core a 3.2GHz) comecei a ler literatura sobre o C++              visto que só em c++ o openmp funciona

5º - Depois de muitas "cabeçadas" na parede e perder muitas horas a ler muitos post's nos foruns da microsoft consegui colocar um prog. de teste

       a compilar sem erros mas depois de compilado aparece-me uma janela com um erro marado o qual eu não sei por onde "pegar".

6º - Falei com uma pessoa amiga que percebe de c++ sobre o openmp (e ajudou-me em muita coisa)

       Resposta: "isso é só para profissionais"

7º - Se houver uma alma caridosa que me queira ajudar ficarei muito agradecido.

8º - Como não sei colocar o ficheiro rar no rapideshare e semelhantes deixo o link do emule

ed2k://|file|teste%20OpenMP.rar|3183779|FFF3F388ACAA1C5A0CA2943A821B6D31|h=EHZCCHRQ74BPGOSFXEXVMUMMZYZJ3ZES|/

9º - WinXP 64bits Pro com SP2 , visual studio pro 2008 com sp1, amd dual core a 3.2Ghz

Cumprimentos

Power

[Marfig]

Olá power,

Estive a ler e parece-me que não tem esta funcionalidade!!

Julgo que as últimas versões do MinGW suportam OpenMP, uma vez se baseiam no gcc 4.x. O útimo gcc em MinGW é o 4.3.0.

Terás que ir ao website do MinGW e fazer o download dos ficheiros. O projecto MinGW não é definitivamente reconhecido por ter um website fácil de navegar. Muitos iniciantes ao C++ queixam-se disto, pelo que tenho de lhes dar razão. Mas pouco posso fazer. A minha participação no projecto tem sido muito pouca nos últimos dois anos e foi sempre limitada ao wiki. O Wiki também é mal construido e muitas páginas não contêm informação ou fazem link para informação noutras secções. No entanto aconselho-te a ler com atenção o "Getting Started" e o "FAQ" na página acima.

O método aconselhável para instalar o MinGW é fazer o download individual das packages e instalar estas uma a uma. No entanto para facilitar a vida a iniciantes, um MinGW Installer foi criado. Ao contrário do que diz na documentação, quando o Installer te perguntar qual a versão do MingW queres instalar (previous, current, ou candidate) deves escolher a candidate. Depois só precisas de escolher g++ e make das opções que te vão ser apresentadas.

3º -  O programa que já está feito em visual basic mas só que eu preciso que o programa faça muitos ciclos for, while, if etc.... +/- 5milhões

Bom... seria interessante saber que programa se trata. Em todo o caso, 5 milhões de construções for, while ou if significa - assumindo que cada construção tem 10 linhas de código em média - 50 milhões de linhas de código somente para isso. Acabast-te de igualar o número de linhas de código aproximado do Windows Vista. Portanto, vê lá bem... não será antes 500? 😛

4º - Como li que o openmp consegue por os 2 cpu's a funcionar em simultaneo (amd dual core a 3.2GHz) comecei a ler literatura sobre o C++              visto que só em c++ o openmp funciona

Acho que estás a ver tudo isto mal.

O facto de teres muitos ifs, whiles ou fors no teu código não quer dizer de modo algum que precisas de threads. Poderiamos discutir aqui se muitos dessas construções seriam necessárias. A minha experiência diz-me que muitos programadores vindos do Visual Basic para o mundo do C++ demoram algum tempo a habituar-se à foma de programar em C++ e tendem a construir programas com gigantescos If-then-else espalhados por todo o lado. Mas deixe-mos isso para trás uma vez que só olhando para o tu código eu poderia perceber se é esse o caso, ou quais os casos em que poderias melhorar o teu código. O impoetante é o seguinte...

Threads não são uma forma de substituir ifs, fors ou whiles. Nem tão pouco se tornam necessárias na presença de muitas destas construções. Multithreading surge na esmagadora maioria dos casos da necessidade de melhorar o desempenho da aplicação. Portanto lá porque tens muitas dessas construções não significa que precises de multithreading. Se partilhares connosco que tipo de aplicação estás a construir, seremos capazes de te dizer se beneficiarás de multithreading, e onde.

6º - Falei com uma pessoa amiga que percebe de c++ sobre o openmp (e ajudou-me em muita coisa)

       Resposta: "isso é só para profissionais"

Com todo o respeito para o teu amigo, ele está profundamente enganado. Alguns dos melhores programadores que tive o prazer de conhecer são amadores e não têm carreiras na área de programação. Outros são ainda estudantes universitários. Outros ainda nem nunca sequer entraram numa faculdade. Outros ainda são estudantes do equivalente ao nosso secundário. Participei em projectos ou observei o desenvolvimento de projectos em que os programadores de topo eram miudos de 16 ou 17(!) anos que brincavam com o meu código!

Na realidade, conheço melhores programadores amadores do que conheço bons programadores profissionais. Portanto não. Isto não é para profissionais. É para toda a gente que quiser estudar e tiver vontade de aprender.

7º - Se houver uma alma caridosa que me queira ajudar ficarei muito agradecido.

O OpenMP tem sérios problemas de implementação que o tornam desaconselhável na maioria dos casos. Por alguma razão nem sequer é considerado uma alternativa a estudar no actual debate para inclusão de multithreading nos standards do C++.

Por um lado é sem dúvida relativamente fácil de utilizar uma vez que a sua implementação assenta em #pragma o que proporciona a vantagem adicional de se o compilador não compreender a macro (o compilador não suporta OpenMP), estas serem ignoradas e o programa compilar à mesma em modo single threaded. Uma outra vantagem (nem sempre uma vantagem, mas lá iremos...) do OpenMP é que implementa um numero indeterminado de threads. O programador não precisa de especificar as threads a criar. Portanto o programa é escalonável em diferentes sistemas (mas ainda assim obriga a uma recompilação pelo que esta vantagem é discutível).

Mas as desvantagens do OpenMP são numerosas e muito importantes, pelo que a sua utilização é realmente limitada aos poucos casos em que não é necessário um grande controle sobre as threads no sentido de evitar race conditions. Nos dias de hoje, e também pela forma como o C++ é implementado e os sistemas operativos desenvolvidos, isso é bastante raro e somente pequenas aplicações beneficiam do OpenMP.

O primeiro grande problema do OpenMP é exactamente resultado da sua grande vantagem. O #pragma. A realidade é que não existe tal coisa como "simples multitheading". Multithreading é um área complexa de desenvolvimento, ponto. Não há volta a dar. Os cuidados que o programador tem de ter e a dificuldade em depurar código multithreading são reconhecidos desde sempre. Ora, a utilização de #pragma tem uma grande desvantagem... considera o seguinte código:

#pragma omp parallel for
for (i=0; i != 5; ++i) {
    lista[i] = lista[i+1];
}

O OpenMP não consegue tratar este código. Uma das limitações do OpenMP, e tavez a mais séria, é que o OpenMP não consegue lidar com flow dependency (quando os resultados de um loop são usados por iterações desse mesmo loop). Em abono da verdade, também não é simples de fazer com outros métodos multithreading. Em todo o caso o problema é mais sério ainda quando consideramos que o OpenMP não consegue detectar estas situações e vai compilar o ciclo for acima com threads e silenciosamente gerar resultados errados!

Fazer debug destas situações é um autêntico pesadelo. E só quem não passou por elas poderá  pensar que não. O código acima é simples. Mas flow dependency é comunm e muitas vezes mais complexo e nem sempre fácil de observar mesmo pelo próprio programador. Pior ainda, flow dependency é quase sempre necessário quando utilizado e não tem alternativas. Ou seja... todo e qualquer ciclo for que use flow dependency tem de usar flow dependency.

O segundo grande problema do OpenMP é o facto de não conseguir alterar a prioridade das threads. Isto é o resultado da sua vantagem de criar thrrads de uma forma escalonável. Mas realmente, nos dias de hoje com a arquitectura 32 e 64 bits é impensável na maioria dos projectos rnvolvendo multithreading não se conseguir alterar a pioridade das threads durante o runtime.

O terceiro problema é, em alguns casos realmente debilitante. Uma dos aspectos importantes do multithreading é a noção se semaphores (semáforos). Em temos de perfomance muitas vezes os semáforos fazem a diferença entre ser vantajoso usar multithreads ou não. A capacidade de threads acederem ao lock criado por outra thread é fundamental em muitos casos, particularmente naqueles casos em que a data não é critica para leitura, mas apenas para escrita - uma situação comum. O OpenMP não suporta semáforos pelo que uma thread que crie um lock tem de terminar antes que qualquer outra thread aceda a esse lock.

O quarto problema, e último na minha lista (há mais, mas estes são partilhados também por outras metodologias de multithreading) é o facto de que a simplicidade de desenvolvimento multithreading com OpenMP é apenas aparente. Essa simplicidade é clara e indiscutivel na observação de que o código com OpenMP é simples e fácil de ler. Isto é inegável. Mas... o OpenMP é um pesadelo para depurar. Não oferece mecanismos de depuração uma vez que assenta em #pragmas, pelo que há pouco que um programador possa fazer para perceber onde está o erro nas suas threads. Por outro lado aqueles inocentes  #pragma fazem uma data de coisas por detrás de palco. Basta olhar para o resultado do primeiro passo da compilação (o pre-processador). Isto significa que o programador perde o controle sobre o seu código e consequentmente a sua capacidade de analisar potenciais problemas durante a fase de desenvolvimento e antes de compilar. O compilador da Intel é o único que oferece algum suporte para depuração do OpenMP e ainda assim é bastante limitado.

...

As metodologias aconselhadas para desenvolvimento de multithrading são discutidas aqui. As referências no fim são também importantes documentos a ler.

Mas o OpenMP não é definitivamente uma ferramenta a ignorar por completo. Pessoalmente, embora não o faça porque me habituei ao boost:threads, vejo o OpenMP como um método adicional a usar em conjunção com outras metodologias para aquelas partes do código cuja implementação seja simples e óbvia. Ou seja, nao me chocaria se um dia visse código com boost::threads por todo o lado, por exemplo, excepto em algumas partes onde o autor usasse OpenMP para controlar pequenas partes do seu código sem ter que recorrer ao boost::threads. Acharia estranho. Mas não me chocaria.

...

Compreendo que a maior parte disto não entendas. Na realidade escrevo-o mais para mim e para os restantes membros do forum que tenham conhecimentos na área de desenvolvimento multithreading. No teu caso, na realidade, a conselho-te a esqueceres multithreading por agora. Concentra-te em aprender C++ e o reto virá naturalmente. Pessoalmente só comecei a perceber threads e a implementá-las com sucesso 3 anos após ter começado a estudar C++. É um tema muito avançado em C++ e é melhor que não te disperses.