Diferenças de desempenho entre ATLAS e MKL?

O ATLAS é um substituto gratuito do BLAS / LAPACK que se ajusta à máquina quando compilado. MKL é a biblioteca comercial fornecida pela Intel. Essas duas bibliotecas são comparáveis ​​no que diz respeito ao desempenho ou o MKL tem a vantagem de algumas tarefas? Se sim, quais são?

O MKL (da Intel) é otimizado para processadores Intel e provavelmente tem a "vantagem" em muitos casos. Mas também é "famoso" por escolher os "piores" caminhos de código para os processadores AMD, conforme descrito aqui .

BLAS não é monlítico. O BLAS1 e o BLAS2 são limitados pela largura de banda da memória e não há muito o que fazer para acelerá-los além do óbvio (desenrolamento de loop, bloqueio de cache para o nível 2). O BLAS3 é mais interessante e a referência prototípica aqui é a multiplicação matriz-matriz. Que eu saiba, o GOTOBlas sempre foi o vencedor aqui, veja, por exemplo, esta comparação ou esta e esta justificativa .

É agora anos depois, e nós temos o Projeto BLIS . É a melhor alternativa gratuita ao MKL.

Perfil, não especule! (também funciona como "Referência, não especule!" )

Não há nada de genérico que se possa dizer, isso depende muito das tarefas que você deseja executar (BLAS 1/2/3, por exemplo) e do hardware em que você está (obviamente, o Intel MKL não roda nos processadores ARM, por exemplo, mas mesmo entre os processadores Intel, você pode esperar diferenças de desempenho).

Outra coisa que acho que vale a pena mencionar é que a AMD também oferece bibliotecas matemáticas ajustadas aos seus processadores, a AMD Core Math Library . Não é tão rico em recursos quanto o MKL da Intel, mas inclui o BLAS.

As respostas anteriores a esta pergunta cobriram a maioria dos pontos mais importantes, mas quero acrescentar um comentário com relação a isso:

MKL tem vantagem sobre algumas tarefas?

A equipe do MKL está em uma posição única para conhecer os futuros conjuntos de instruções da Intel e suas implementações em processadores específicos. Além disso, eles têm acesso a simuladores de processador proprietários e hardware de pré-produção que ninguém fora da Intel pode usar. Assim, a MKL tem vantagem no que diz respeito ao grau de conhecimento sobre produtos futuros e quando eles obtêm esse conhecimento. Portanto, não deve ser muito surpreendente se eles produzirem melhores implementações do BLAS do que qualquer outra pessoa, pelo menos no início da vida útil de um produto com novos recursos.

Por outro lado, a Intel tem sido bastante aberta sobre o conjunto de instruções do AVX-512 e forneceu o Emulador de desenvolvimento de software Intel® (SDE) que permite aos desenvolvedores emular as instruções do AVX-512 em processadores que não as suportam nativamente. Por esse motivo, não será de surpreender se as implementações de código aberto de alta qualidade do BLAS estiverem disponíveis para os processadores Intel que suportam o AVX-512 no início da vida útil desses produtos.

Obviamente, quanta diferença faz para ter informações detalhadas sobre um processador específico versus os fundamentos de algoritmos de álgebra linear densa não é totalmente resolvido. A citação a seguir aborda esse problema melhor do que eu:

Em teoria, não há diferença entre teoria e prática. Mas, na prática, existe.

Divulgação completa: Trabalho para a Intel.

Penso que a principal diferença entre as bibliotecas BLAS do fornecedor e as bibliotecas BLAS de código aberto é o tempo que leva para o código aberto suportar os recursos de hardware mais recentes.

Como o BLAS é amplamente usado, é do interesse do fornecedor oferecer suporte aos recursos de hardware mais recentes. Por exemplo, considere as extensões vetoriais AVX da Intel que foram introduzidas com o processador "ponte de areia" em janeiro de 2011. O MKL tinha suporte para AVX antes mesmo de a CPU estar disponível, mas apenas recentemente o ATLAS (final de 2011) começou a implementar o suporte para AVX .

Além disso, se seu aplicativo realmente precisa de desempenho e antes de começar a comparar diferentes bibliotecas BLAS ou começar a otimizar qualquer coisa: crie um perfil de seu aplicativo. É comum que a intuição humana não seja um preditor de perfil muito eficaz, pelo menos eu sei que a minha não é! Portanto, em vez de gastar tempo otimizando aleatoriamente, analise seu aplicativo e aborde sistematicamente cada gargalo.