Qual é a linguagem de programação mais usada na computação de alto desempenho? E porque? [fechadas]

Acredito que muito Fortran é usado no HPC, mas não tenho certeza se isso é apenas por motivos herdados.

Recursos de linguagens de programação modernas, como coleta de lixo ou polimorfismo em tempo de execução, não são adequados para o HPC, pois a velocidade é importante, portanto, não tenha certeza de onde C #, Java ou C ++ entra.

Alguma ideia?

Eu já vi muito Java usado para HPC em áreas onde (1) há pouco código legado e (2) o tempo de desenvolvimento e a qualidade do código são importantes. Os domínios de aplicação típicos são finanças, mineração de dados ou bioinformática.

Realmente depende da aplicação (existe vida fora da álgebra linear), mas o desempenho das JVMs recentes geralmente está no mesmo nível do código C. Às vezes, mais rápido quando a JVM é capaz de executar em tempo de execução otimizações inteligentes que os compiladores estáticos (C, Fortran) não podem fazer. E definitivamente mais rápido quando há muita computação simbólica.

Dado um tempo fixo para o desenvolvimento do programa, o código Java resultante é consistentemente mais rápido que o código C. O HPC em Java definitivamente faz sentido quando o código é desenvolvido ou modificado com frequência. Outro recurso importante é a mobilidade do código em diferentes hardwares.

Você encontrará referências em http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

Com relação à suposição de Fortran de que dois endereços são únicos, estamos trabalhando em uma ferramenta de análise estática que permitirá otimizações semelhantes para código em linguagens de alto nível, mas sem o bit "Bad Things May Happen". Entre em contato comigo se estiver interessado.

Nos meus anos de experiência, até 5 anos atrás, sempre foram Fortran e C. Qual deles dependia principalmente se as pessoas vinham mais da engenharia ou mais da escola de pensamento de CS (não sei como colocar isso melhor , ok? :-)

No que estávamos fazendo, o Fortran foi usado quase que exclusivamente.

Pelo que li hoje em dia, com as novas atualizações do Padrão F2003 / 08 e com a introdução dos Co-Arrays, parece estar ganhando força novamente.

Além disso, um artigo, se não um pouco tendencioso - The Ideal HPC Programming Language

Eu acho que para o pedal de verdade, a única opção real é o Fortran. O raciocínio é que o mais importante para a exploração de ILP de baixo nível (paralelismo no nível de instrução) é a desambiguação de endereço de memória. As regras de definição no Fortran permitem que o compilador determine que dois endereços são únicos (e, portanto, a ordem de cargas e armazenamento, ou mesmo armazenamentos e armazenamentos podem ser trocados sem risco de gerar código incorreto). C deixa muito espaço para ponteiros sobrepostos para o compilador extrair o mesmo paralelismo de baixo nível do código.

Além disso, o alinhamento da matriz, as linhas de cache wrt e os limites SSE / AVX são importantes para a geração e execução de loops eficientes. Se as matrizes forem passadas por blocos comuns, o compilador / carregador poderá garantir que todas as matrizes iniciem nos mesmos limites de alinhamento de endereço e que cargas e armazenamentos mais eficientes do SSE / AVX possam ser utilizados. O hardware mais recente pode lidar com acessos de memória desalinhados, mas, como o acesso à memória não está alinhado, o uso parcial das linhas de cache resulta em menor desempenho. Mesmo que um programador C alinhe corretamente todas as suas matrizes, existe um mecanismo para comunicar isso ao compilador?

Para resumir, as duas questões mais importantes são a independência dos endereços de memória e o reconhecimento pelo compilador de que as estruturas de dados acessadas têm o mesmo alinhamento "natural" que o hardware deseja. Até agora, o Fortran faz o melhor trabalho nessas duas tarefas.

Apenas uma nota anedótica. Eu também não fiz computação de alto desempenho.

Para cálculos (processamento de números), Fortran e C. Sim, é por motivos herdados:

• Ampla disponibilidade de código fonte e receitas de domínio público.
• Ambos suportam MPI .
• Os dois idiomas são compilados.
• Compiladores para ambos os idiomas são fornecidos por todos os SOs e fornecedores HPC.
• Compiladores vetorizadores estão disponíveis.
• Ambos requerem um nível louco de ajustes para obter alto desempenho quando transportados para um cluster diferente (tamanho de memória diferente, número de CPUs, etc.)
  • Na verdade, isso explica por que o código-fonte aberto é importante: é necessário fazer ajustes, portanto, a receita original deve ser escrita em um idioma adequado para ajustes manuais.

A tendência atual do processamento de números é escrever geradores de programas que automatizem os ajustes do código-fonte para otimizar o desempenho, dadas as características do cluster. Esses geradores geralmente produzem em C.

Uma segunda tendência é escrever em algum dialeto especializado de C para GPUs específicas ou Cell BE.

Para trabalhos não numéricos, como programas que processam dados de um banco de dados (mas não o próprio banco de dados), é muito mais barato executar em clusters de máquinas "comuns" sem os caros equipamentos de rede personalizados. Isso geralmente é chamado de "Computação de alto rendimento". E Python é a linguagem nº 1 aqui (usando o famoso Map Reduce). Antes do Python, os projetos de processamento em lote podem ser escritos em qualquer idioma e geralmente são despachados pelo Condor .

Eu tenho trabalhado em algum código MUITO intensivo de cálculo em (suspiro!) C #.

Estou construindo uma implementação GPGPU do FDTD para modelagem óptica. Em um pequeno cluster (128 processadores), muitas de nossas simulações levam semanas para serem executadas. As implementações de GPU, no entanto, tendem a rodar cerca de 50x mais rapidamente - e isso é uma placa NVidia de nível de consumidor. Agora temos um servidor com duas placas de processador duplo GTX295 (várias centenas de núcleos) e, em breve, receberemos alguns Teslas.

Como isso se aplica ao seu idioma? Da mesma forma que o código C ++ FDTD que estávamos usando antes era vinculado à CPU, eles são vinculados à GPU, portanto a diferença ( muito pequena) de potência entre código gerenciado e código nativo nunca entra em jogo. O aplicativo C # atua como um condutor - carregando kernels OpenCL, transmitindo dados de e para as GPUs, fornecendo a interface do usuário, relatórios etc. - todas as tarefas que são chatas no C ++.

No passado, a diferença de desempenho entre código gerenciado e não gerenciado era significativa o suficiente para às vezes valer a pena aturar o terrível modelo de objetos do C ++ para obter a porcentagem extra de velocidade. Atualmente, o custo de desenvolvimento de C ++ vs C # supera em muito os benefícios para a maioria dos aplicativos.

Além disso, a maior parte de sua diferença de desempenho não virá da sua escolha de idioma, mas da habilidade do seu desenvolvedor. Algumas semanas atrás, movi uma operação de divisão única de dentro de um loop tripla aninhada (3D array atravessar), que reduziu o tempo de execução para um determinado domínio computacional em 15%. Isso é resultado da arquitetura do processador: a divisão é lenta, que é uma daquelas faces que você só precisa entender em algum lugar.

O Fortran é o mais comum, principalmente devido ao legado (as pessoas ainda executam códigos antigos) e à familiaridade (a maioria das pessoas que faz HPC não conhece outros tipos de idiomas).

Recursos de linguagens de programação modernas, como coleta de lixo ou polimorfismo em tempo de execução, não são adequados para o HPC, pois a velocidade é importante, portanto, não tenha certeza de onde C #, Java ou C ++ entra.

Isso não é verdade em geral. O HPC clássico fazia principalmente álgebra linear com números de precisão da máquina. No entanto, o HPC moderno está cada vez mais usando supercomputadores para uma variedade maior de trituração, como cálculos simbólicos com expressões matemáticas arbitrárias em vez de números de precisão da máquina. Isso coloca características bastante diferentes nas ferramentas usadas e não é incomum usar linguagens de programação diferentes do Fortran, porque a computação simbólica pode ser proibitivamente difícil sem o GC e outros tipos de compilador de otimização, como o compilador de correspondência de padrões de otimização do OCaml.

Por exemplo, leia este artigo de Fischbacher et al. que diz "os autores têm fortes razões para acreditar que esse pode ser o maior cálculo simbólico realizado até agora".

Fortran, por algumas boas e outras não tão boas razões. Para um processamento matemático pesado, uma boa razão é que existem bibliotecas extensas (BLAS, LAPACK) de sub-rotinas testadas e verdadeiras, todas escritas em Fortran (embora possam ser chamadas de C e C ++).

Um motivo não tão bom é a suposta vantagem de desempenho do Fortran sobre C / C ++. Os otimizadores são muito bons e poucas pessoas entendem que o benefício de otimizar um trecho de código é proporcional à porcentagem de tempo em que ele está ocupado, o que em quase todo o código é quase zero.

Outro motivo não tão bom é uma lacuna cultural entre programadores de CS e não-CS. Os programadores científicos tendem a aprender maus hábitos no Fortran, a menosprezar os programadores de CS e os maus hábitos que foram ensinados, e os menosprezados.

Basicamente, todos os programas que realizam o trabalho de trituração de números ainda são FORTRAN (os antigos blas, lapack, arnoldi etc. ainda são os usados) ... No entanto, quando se trata de estrutura de nível superior ... as pessoas estão usando cada vez mais C ++.

A complexidade da simulação envolve código imenso e, para obter qualquer tipo de benefício ao escrever um, é torná-lo reutilizável. Além disso, os conceitos utilizados também se tornaram muito complexos. É quase loucura representar essa informação usando FORTRAN. É aí que entra o C ++, pois suporta inerentemente o Design Orientado a Objetos. No entanto, o polimorfismo em tempo de execução raramente é preferido. As pessoas quase sempre usam polimorfismo estático (que é implementado em C ++ com meta-programação de modelos)

Além disso, agora os compiladores são realmente bons, portanto, muita otimização é deixada para os compiladores.

Existem dois tipos de problemas que precisam ser resolvidos nos aplicativos HPC: um é o número de processamento e o outro é o gerenciamento de cálculos. O primeiro é geralmente abordado com código escrito em Fortran, C ou C ++, devido à velocidade e ao fato de já existirem muitos algoritmos científicos escritos nessas linguagens. A direção dos cálculos é mais convenientemente implementada em linguagens de nível superior. Python é uma linguagem de "cola" de escolha para lidar com a lógica do aplicativo e chamar extensões implementadas em linguagens compiladas. Java é freqüentemente usado por projetos nos quais o gerenciamento de redes e computação distribuída é essencial.