Qual o futuro que a GPU tem em computação? [fechadas]

https://stackoverflow.com/questions/1126989

13-09-2019
|

Pergunta

Seu processador pode ser um quad-core, mas você sabia que algumas placas gráficas de hoje têm mais de 200 núcleos? Nós já vimos o GPU está em placas gráficas de hoje pode fazer quando se trata de gráficos. Agora eles podem ser usados ??para tarefas não-gráficos, bem como, e na minha opinião, os resultados são nada menos que incrível. Um algoritmo que se presta bem a paralelismo tem o potencial de ser muito, muito mais rápido em uma GPU do que poderia estar em uma CPU.

Existem algumas tecnologias que tornam tudo isso possível:

1). CUDA por NVidia. Parece ser a mais conhecida e bem documentada. Infelizmente, ele só irá funcionar em placas de vídeo NVidia. Eu fiz o download do SDK, experimentou algumas das amostras, e há algumas coisas incrível que está sendo feito em CUDA. Mas o fato de que ele é limitado para placas NVidia me faz questionar o seu futuro.

2.) Fluxo por ATI. equivalente de ATI para CUDA. Como você poderia esperar, ele só irá funcionar em placas ATI.

3) OpenCL -. O Khronos Group reuniu esta padrão, mas ele ainda está em seus estágios da infância. Eu gosto da idéia de OpenCL embora. A esperança é que ele deve ser apoiada pela maioria dos fabricantes de placas de vídeo e deve tornar o desenvolvimento cartão de cross-vídeo que muito mais fácil.

Mas que outras tecnologias para a programação GPU não-gráfico estão chegando e que mostra o mais promissor? E você vê ou você gostaria de ver essas tecnologias que estão sendo construídos em alguns dos quadros de desenvolvimento tradicionais, como .NET para torná-lo muito mais fácil?

Solução

Eu prevejo que esta tecnologia vai se tornar popular e mainstream, mas vai demorar algum tempo para fazê-lo. Meu palpite é de cerca de 5 a 10 anos.

Como você observou corretamente, um grande obstáculo para a adoção da tecnologia é a falta de uma biblioteca comum que roda na maioria dos adaptadores - ATI e nVidia. Até que isso seja resolvido para um grau aceitável, a tecnologia não vai entrar mainstream e vai ficar no nicho de aplicações personalizadas feitas que são executados em hardware específico.

Quanto à integração com C # e outras linguagens gerenciados de alto nível - o que irá demorar um pouco mais, mas XNA já demonstra que shaders personalizados e ambiente gerenciado pode misturar juntos - até certo ponto. Claro, o código de shader ainda não está em C #, e existem vários grandes obstáculos para fazê-lo.

Uma das principais razões para a rápida execução de código GPU é que ele tem graves limitações sobre o que o código pode e não pode fazer, e ele usa VRAM em vez de RAM habitual. Isso torna difícil para reunir código de CPU e GPU código. Enquanto soluções alternativas são possíveis, eles praticamente anular o ganho de desempenho.

Uma possível solução que vejo é fazer um sub-idioma para C #, que tem as suas limitações, é compilado para código GPU, e tem uma forma estritamente definida de se comunicar com o código ususal C #. No entanto, isso não seria muito diferente do que o que já temos - apenas mais confortável para escrever por causa de algum açúcar sintático e funções da biblioteca padrão. Ainda assim, isso também é idades afastado por agora.

Outras dicas

Eu acho que você pode contar a próxima DirectX como uma outra maneira de usar a GPU.

Da minha experiência, as GPUs são extremamente rápidos para algoritmos que são fáceis de paralelizar. Recentemente otimizado um algoritmo especial imagem redimensionamento em CUDA para ser mais de 100 vezes mais rápido na GPU (nem mesmo um high-end) do que um processador quad core Intel. O problema foi recebendo os dados para a GPU e, em seguida, ao obter o resultado de volta para a memória principal, ambos os sentidos limitados pela velocidade memcpy () em que a máquina, o que era menos do que 2 Gb / s. Como resultado, o algoritmo foi apenas ligeiramente mais rápido do que a versão CPU ...

Então, ele realmente depende. Se você tiver uma aplicação científica onde você pode manter a maioria dos dados na GPU, e todos os algoritmos de mapear para uma implementação GPU, então tudo bem. Mais eu iria esperar até que haja um tubo mais rápida entre CPU e GPU, ou vamos ver o que a ATI tem as mangas com um chip combinado ...

Sobre o que a tecnologia para uso: Eu acho que uma vez que você tem suas coisas funcionando em CUDA, o passo adicional para porta-lo para OpenCL (ou outro idioma) não é tão grande. Você fez todo o trabalho pesado por paralelização seus algoritmos, eo resto é apenas um 'sabor' diferente

Monte Carlo é embaraçosamente paralelo, mas é uma técnica nuclear em computação financeira e científica.

Um dos entrevistados é ligeiramente incorreto dizer que a maioria dos desafios do mundo real não são decomposable facilmente para estes tipos de tarefas.

investigação científica tractible Muito é feito aproveitando o que pode ser expresso de forma embaraçosamente paralelo.

Só porque ele é chamado de "vergonhosamente" paralelo não significa que ele não é um campo extremamente importante.

Eu trabalhei em várias casas financeiras, e prevejo que podemos jogar fora fazendas de 1000 motores de Montecarlo (muitas pilhas de lâminas alinharam juntos) para várias instalações grandes NVidia CUDA - maciçamente diminuir os custos de energia e de calor no centro de dados.

Uma das vantagens de arquitetura significativa é que há muito menos rede de carga também, como há muito menos máquinas que precisam ser alimentados com dados e comunicarão os resultados.

Fundamentalmente no entanto tais tecnologias estão em um nível de abstração mais baixo do que uma linguagem tempo de execução gerenciado como C #, estamos a falar de dispositivos de hardware que funcionam seu próprio código em seus próprios processadores.

A integração deve primeiro ser feito com Matlab, Mathematica eu esperaria, junto com as APIs C, é claro ...

Outra tecnologia que está vindo para o processamento baseado em GPU é versões de GPU de bibliotecas computacionais de alto nível existentes. Não muito chamativo, eu sei, mas tem vantagens significativas para código portátil e facilidade de programação.

Por exemplo, Stream 2.0 SDK da AMD inclui uma versão do seu BLAS (álgebra linear) biblioteca com alguns dos cálculos implementados na GPU. A API é exatamente o mesmo que a sua versão somente CPU da biblioteca que tenho enviado por anos e anos; tudo que é necessário é religação da aplicação, e ele usa a GPU e corre mais rápido.

Da mesma forma, Dan Campbell em GTRI vem trabalhando em uma implementação CUDA do padrão VSIPL para processamento de sinal. (Em particular, o tipo de sinal e processamento de imagem que é comum em sistemas de radar e coisas relacionadas, como imagens médicas.) Mais uma vez, isso é uma interface padrão e aplicativos que foram escritos para implementações VSIPL em outros processadores podem simplesmente ser recompilados com um presente e utilizar a capacidade da GPU quando necessário.

Na prática, esses dias já bastante programas numéricos de alto desempenho não fazer sua própria programação de baixo nível, mas dependem de bibliotecas. Em hardware Intel, se você está fazendo números impressionantes, é geralmente difícil de bater as bibliotecas de matemática Intel (MKL) para a maioria das coisas que ele implementa - e usá-los significa que você pode obter as vantagens de todas as instruções vetoriais e truques inteligentes em processadores x86 mais recentes, sem ter de se especializar seu código para eles. Com coisas como GPUs, eu suspeito que isso vai se tornar ainda mais prevalente.

Então eu acho que uma tecnologia para relógio é o desenvolvimento de bibliotecas de uso geral que forma núcleo blocos de construção para aplicações em domínios específicos, de forma que as peças de captura desses algoritmos que podem ser enviados de forma eficiente off para a GPU, minimizando a quantidade de específico-GPU não portável esperteza exigido a partir do programador.

(Viés disclaimer:! Minha empresa também tem trabalhado em uma porta CUDA da biblioteca de nosso VSIPL ++, por isso estou inclinado a pensar que este é uma boa idéia)

Além disso, em uma direção totalmente diferente, que você pode querer verificar para fora algumas das coisas que RapidMind está fazendo. Sua plataforma foi inicialmente destinado a sistemas do tipo CPU multicore, mas eles estão fazendo um bom bocado de trabalho que se estende para computações GPU também.

qualquer coisa bonita que pode ser comparado pode ser capaz de benefício. Exemplos mais específicos seria SETI @ home, o Folding @ home, e outros projetos distribuídos, bem como computação científica.

Especialmente coisas que dependem fortemente de aritmética de ponto flutuante. Isso ocorre porque GPUs se especializaram circuitos que é muito rápido em operações de ponto flutuante. Isto significa que não é tão versátil, mas é muito bom no que ele faz.

Se você quer olhar para processamento de GPU mais dedicado, veja da Nvidia Tesla GPU . É uma GPU, mas na verdade não tem uma saída de monitor!

Eu duvido que veremos muito processamento GPU no ambiente de trabalho comum, ou pelo menos por um tempo, porque nem todo mundo tem um CUDA ou placa gráfica capaz semelhante, se eles ainda têm uma placa gráfica em tudo. É também muito difícil de tornar os programas mais paralelo. Jogos poderia utilizar este poder extra, mas será muito difícil e, provavelmente, não vai ser muito útil, já que todos os cálculos de gráficos são na sua maioria já na GPU e o outro trabalho é sobre a CPU e tem para estar no CPU devido aos conjuntos de instruções.

processamento de GPU, ao menos por um tempo, será para nichos de mercado muito específicos que precisam de muita flutuante computação ponto.

É importante ter em mente que mesmo as tarefas que são benefício pode inerentemente série de paralelização se eles devem ser executadas muitas vezes de forma independente.

Além disso, tenha em mente que sempre que alguém relata a aceleração da implementação de um GPU para uma implementação de CPU, ele quase nunca é uma comparação justa. Para ser verdadeiramente justo, os implementadores devem primeiro passar o tempo para criar um verdadeiramente otimizado, implementação CPU paralelo. Um único Intel Core i7 965 XE CPU pode atingir cerca de 70 gigaflops em precisão dupla hoje. Atuais GPUs high-end pode fazer 70-80 gigaflops em dupla precisão e cerca de 1000 em precisão simples. Assim, um aumento de velocidade de mais de 15 pode implicar uma implementação CPU ineficiente.

Uma ressalva importante com a computação em GPU é que é atualmente "pequena escala". Com uma facilidade de supercomputação, você pode executar um algoritmo paralelizado em centenas ou mesmo milhares de núcleos de CPU. Em contraste, a GPU "clusters" são actualmente limitada a cerca de 8 GPUs conectados a uma máquina. Claro, várias dessas máquinas podem ser combinadas entre si, mas isso aumenta a complexidade adicional, tal como os dados devem não só passar entre computadores, mas também entre GPUs. Além disso, ainda não há um equivalente MPI que permite que os processos de forma transparente escala para várias GPUs em várias máquinas; esta deve ser realizada manualmente (possivelmente em combinação com MPI).

Além deste problema de escala, a outra grande limitação de GPUs para computação paralela é a restrição severa nos padrões de acesso de memória. acesso à memória aleatório é possível, mas o acesso à memória cuidadosamente planejada resultará em muitas vezes um melhor desempenho.

Talvez o próximo candidato mais promissor é Larrabee da Intel. Tem consideravelmente melhor acesso ao CPU, memória do sistema, e, talvez mais importante, cache. Isso deve dar-lhe vantagens consideráveis ??com muitos algoritmos. Se ele não pode corresponder a largura de banda de memória enorme sobre GPUs atuais, porém, pode ser lag atrás da concorrência para algoritmos que otimamente usar essa largura de banda.

A atual geração de hardware e software requer um grande esforço desenvolvedor para obter o desempenho ideal. Isso muitas vezes inclui reestruturação algoritmos para fazer uso eficiente da memória da GPU. É também muitas vezes envolve a experimentar com diferentes abordagens para encontrar o melhor.

Note também que o esforço necessário para obter o desempenho ideal é necessário para justificar o uso de hardware GPU. A diferença entre uma implementação simples e uma implementação optimizada pode ser de uma ordem de grandeza ou mais. Isto significa que um impelemntation CPU otimizado provavelmente será tão bom ou ainda melhor do que uma implementação GPU ingênuo.

As pessoas já estão trabalhando em .NET ligações para CUDA. Consulte aqui . No entanto, com a necessidade de trabalhar em um nível baixo, eu não acho que GPU computing está pronto para as massas ainda.

Já ouvi muita conversa sobre transformando o que hoje são GPU em mais de uso geral "unidades variedade proceesor", para uso com o qualquer problema de matemática de matriz, em vez de apenas de processamento gráfico. Eu não tenho visto muito vir dele ainda though.

A teoria era que os processadores de matriz pode seguir mais ou menos a mesma trajetória que processadores de ponto-flutuante seguido de um par de décadas antes. Originalmente processadores de ponto flutuante eram caros add-on opções para PC do que não um monte de gente se preocupou em comprar. Eventualmente, eles se tornou tão vital que eles foram colocados na própria CPU.

Eu vou repetir a resposta que dei aqui.

longo prazo eu acho que a GPU vai deixar de existir, como processadores de uso geral evoluir para assumir essas funções. Larrabee da Intel é o primeiro passo. A história tem mostrado que apostar contra x86 é uma má idéia.

GHC (Haskell) pesquisadores (que trabalham para Microsoft Research) está adicionando suporte para Nested Paralelismo de dados diretamente para uma linguagem de programação de propósito geral. A idéia é usar múltiplos núcleos e / ou GPUs no back-end ainda expor dados matrizes paralelas como um tipo nativo na língua, independentemente do tempo de execução executar o código em paralelo (ou de série para o fallback com uma única CPU).

http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell

Dependendo do sucesso desta nos próximos anos, eu esperaria ver outras línguas (C # especificamente) pegar a idéia, o que poderia trazer esses tipos de capacidades para um público mais mainstream. Talvez por esse tempo a largura de banda CPU-GPU e problemas de driver será resolvido.

GPUs trabalham bem em problemas onde há um alto nível de dados em nível paralelismo , a qual, essencialmente, significa que existe um caminho para particionar os dados a serem processados ??de tal modo que todos eles podem ser processados.

GPUs não são inerentemente mais rápido em um nível velocidade de clock. De fato, eu sou relativamente certeza de que a velocidade do clock nos shaders (ou talvez eles têm um prazo GPGPU mais para eles nos dias de hoje?) É bastante lento em comparação com os ALUs em um processador para desktop moderno. A coisa é, a GPU tem um absolutamente enorme quantidade desses shaders, transformando a GPU em um muito grande processador SIMD . Com a quantidade de shaders em uma Geforce moderna, por exemplo, é possível para uma GPU estar trabalhando em várias centenas (milhares?) Números de ponto flutuante ao mesmo tempo.

Assim suma, uma GPU pode ser incrivelmente rápido para problemas em que você pode particionar os dados corretamente e processar as partições de forma independente. Não é tão poderoso em Task (thread) Nível Paralelismo .

Um grande problema com a tecnologia GPU é que, enquanto você tem um monte de capacidade de computação lá, recebendo dados em (e fora dele) é terrível (performance-wise). E observar cuidadosamente para qualquer referência de comparação ... eles costumam comparar gcc (com otimização mínima, sem vetorização) em um sistema de processador único para a GPU.

Outro grande problema com a GPU de é que se você não pensar cuidadosamente sobre como os dados são organizados, você vai sofrer um desempenho verdadeiro sucesso internamente (na GPU). Isso muitas vezes envolve reescrever o código muito simples em uma pilha complicada de lixo.

Estou muito animado com esta tecnologia. No entanto, penso que isso só vai agravar o verdadeiro desafio de tarefas paralelas grandes, um de largura de banda. Adicionando mais núcleos só vai aumentar contenção de memória. OpenCL e outras bibliotecas GPGPU abstração não oferecem quaisquer ferramentas para melhorar isso.

Qualquer plataforma hardware de alta performance de computação geralmente será concebido com a questão da largura de banda cuidadosamente planejado para o hardware, equilibrando o throughput, latência, caching e custo. Enquanto hardware commodity, CPU e GPU, são projetados de forma isolada um do outro, com largura de banda otimizada apenas para a memória local, será muito difícil melhorar isso para os algoritmos que precisam dele.

É verdade que GPUs pode alcançar números de desempenho muito hi em situações de paralelismo de nível de dados, como muitos aqui mencionados. Mas, como eu vê-lo, não há muita utilidade para ele no espaço do usuário agora. Eu não posso sensação ajuda que toda a propaganda deste GPGPU vem de fabricantes de GPU, que só querem encontrar novos mercados e usos para seus produtos. E isso é absolutelly ok. Alguma vez você já se perguntou por Intel / AMD não funcionavam incluem alguns núcleos mini-x86, além de os quartos standard (digamos - modelo com quatro x 86 núcleos e 64 mini--x86-núcleos), apenas para aumentar capabilties nível de dados paralelismo? Eles definitivamente poderia fazer isso, se quisesse. Meu palpite é que a indústria só precisa não faça esse tipo de poder de processamento em máquinas desktop / servidor regulares.

GPUs pode ou não permanecer tão popular como eles estão agora, mas a idéia básica é tornar-se uma abordagem bastante popular para processamento de alta potência. Uma tendência que está surgindo agora é o "acelerador" externa para ajudar o CPU com grandes trabalhos de ponto flutuante. A GPU é apenas um tipo de acelerador.

A Intel está lançando um novo acelerador chamado Xeon Phi , o que eles estão esperando pode desafiar o GPU como um acelerador de HPC. A celular teve uma abordagem semelhante, dotada de uma CPU principal para fazer tarefas gerais, e descarga tarefas de computação intensiva para alguns outros elementos de processamento, conseguindo algumas velocidades impressionantes.

Aceleradores em geral parecem ser de interesse no momento, assim que deve ser em torno de um tempo, pelo menos. Quer ou não os restos GPU como o de facto acelerador continua a ser visto.

A sua percepção de que GPUs são mais rápido do que CPUs é baseada no equívoco criado por algumas aplicações embarassingly paralelas aplicada aos gostos do PS3, hardware NVIDIA e ATI.

http://en.wikipedia.org/wiki/Embarrassingly_parallel

A maioria dos desafios do mundo real não são decomposable facilmente para estes tipos de tarefas. A CPU desktop é melhor maneira adequada para este tipo de desafio tanto de um conjunto de recursos e desempenho ponto de vista.

Espero que as mesmas coisas que CPUs são usados ??para?

Eu só quero dizer isto parece como um chamariz para mim. Hesito em dizer "que está indo a lugar nenhum" quando se trata de tecnologia, mas GPUs função primária é renderização de gráficos e CPUs função principal é todos os outro processamento. Ter a GPU fazer qualquer outra coisa apenas parece whacky.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow