Não consigo responder a segunda metade da sua pergunta em relação a outras implementações existentes, mas posso fornecer algumas dicas sobre os desafios. Para referência, eu pessoalmente usei o ViennaCL em uma nVidia GTX 560 Ti com 2 GB de memória para meus benchmarks.
Sobre o código de série em um i5 de gama média, vi acelerações para multiplicações densas de matriz de aproximadamente 40x. Para operações como uma multiplicação vetorial escalar, vi velocidades de 1000x. O gorila de 800 libras na sala, no entanto, é a largura de banda da memória. Para a maioria das GPUs comerciais, você usará algo como PCIe, que limita a cerca de 6 GB / s de taxa de transferência. No meu caso, enquanto o cálculo era 40x mais rápido, as três cópias matriciais (duas para a GPU e uma para trás) demoravam tanto tempo quanto a computação na CPU.
O problema, então, com qualquer biblioteca geral de álgebra linear da GPU, é que eles não podem realmente reutilizar objetos na GPU, porque não sabem o que você fará com eles. Portanto, toda chamada para um kernel de computação provavelmente precisará copiar para a GPU e, em seguida, copiar o resultado novamente. Isso consumirá grande parte dos ganhos.
Se você puder reutilizar objetos como matrizes, poderá escrever algoritmos de nível superior para evitar o máximo de gerenciamento de memória possível, mas seria difícil pressionar uma biblioteca para fazer isso com eficiência.
Espero que isso ajude, e tenho certeza de que há outras pessoas aqui com muito mais experiência nisso, mas essas são as experiências e impressões que recebi durante minha curta incursão na computação em GPU.
Deixe-me focar apenas em CUDA e BLAS.
A aceleração em uma implementação de BLAS do host não é uma boa métrica para avaliar a taxa de transferência, pois depende de muitos fatores, embora eu concorde que a aceleração geralmente é o que importa.
Se você olhar para os benchmarks publicados pela NVIDIA e levar em consideração que o Tesla M2090 tem desempenho máximo de 1331 Gigaflops (precisão única) e 665 Gigaflops (duplo prec.), Verá que, para o SGEMM e o DGEMM, temos uma taxa de transferência medida quase em 60% do teórico, o que é muito bom.
No que diz respeito à taxa de transferência sustentada de ponto flutuante, acho que os flops devem ser calculados sem levar em consideração os tempos de transferência de dados e resultados, e isso dificulta as comparações de aceleração. Além disso, você deve levar em consideração o tamanho da matriz, pois o melhor desempenho é para matrizes grandes.
Conclusão: a aceleração de um aplicativo da vida real pode ser muito diferente do desempenho medido em pico nas rotinas de álgebra linear, pois é necessário levar em consideração a inicialização da GPU, os tempos de transferência de dados, etc.
Portanto, não responderei sua pergunta sobre a biblioteca mais rápida, pois a pergunta não faz sentido, a menos que uma métrica e um problema precisos sejam definidos. Tudo isso dito, acho que cuBLAS e MAGMA são um bom ponto de partida.
fonte