Entrevista: A promessa da Intel oneAPI e do Direct Parallel C++

Intel não é o primeiro nome que vem à mente quando se pensa em desenvolvimento de software, embora seja uma das empresas de tecnologia mais influentes e inovadoras do planeta. Quatro décadas atrás, o processador 8088 da Intel ajudou a lançar a revolução do PC e, se você estiver lendo isso em um desktop ou laptop, é provável que tenha um Intel Inside. O mesmo vale para servidores e uma variedade de outros hardwares nos quais confiamos todos os dias. Isso não quer dizer que a AMD e outros fornecedores não tenham produtos competitivos porque têm, mas a Intel ainda domina o mercado de CPU x86.

Os engenheiros de software usam as plataformas de hardware Intel há décadas, normalmente sem sequer considerar o software e o firmware por trás delas. Se eles precisassem de mais desempenho de virtualização, eles optaram por produtos multicore, Hyperthreaded Core i7 ou Xeon. Para mexer no banco de dados local, eles podem obter um SSD Intel. Mas agora, a Intel quer que os desenvolvedores comecem a usar mais softwares também.

O que é Intel oneAPI?

Entre no oneAPI, apresentado pela Intel como um modelo de programação único e unificado que visa simplificar o desenvolvimento em diferentes arquiteturas de hardware: CPUs, GPUs, FPGAs, aceleradores de IA e muito mais. Todos eles têm propriedades muito diferentes e se destacam em diferentes tipos de operações.

A Intel agora está comprometida com uma estratégia “software-first” e espera que os desenvolvedores tomem conhecimento. A grande ideia por trás do oneAPI é permitir o uso de uma plataforma para uma variedade de hardwares diferentes, portanto, os desenvolvedores não precisariam usar linguagens, ferramentas e bibliotecas diferentes ao codificar CPUs e GPUs, por exemplo. Com oneAPI, a caixa de ferramentas e a base de código seriam as mesmas para ambos.

Para tornar isso possível, a Intel desenvolveu o Data Parallel C++ (DPC++) como uma alternativa de código aberto para linguagens proprietárias normalmente usadas para programar para hardware específico (por exemplo, GPUs ou FFPGAs). Essa nova linguagem de programação deve fornecer a produtividade e a familiaridade do C++, ao mesmo tempo em que inclui um compilador para implantação em diferentes destinos de hardware.

O Data Parallel C++ também incorpora o SYCL do Khronos Group para suportar paralelismo de dados e programação heterogênea. Atualmente, a Intel oferece acesso gratuito ao seu DevCloud, permitindo que os engenheiros de software experimentem suas ferramentas e mexam com oneAPI e DPC++ na nuvem sem muitos problemas.

Mas espere, ele funcionará em hardware feito por outros fornecedores? E o licenciamento, é gratuito? Sim e sim: o oneAPI foi projetado para ser independente de hardware e de código aberto, e isso não mudará.

Para saber mais sobre o oneAPI, discutimos sua gênese e futuro com Sanjiv M. Shah, vice-presidente do Grupo de Arquitetura, Gráficos e Software da Intel e gerente geral de Computação Técnica, Empresarial e em Nuvem da Intel.

Sanjiv: Em termos do que está em uma API, penso nisso como quatro partes. Uma é uma linguagem e uma biblioteca padrão, a segunda é um conjunto de ferramentas de aprendizado profundo, a terceira é realmente uma camada de abstração de hardware e uma camada de driver de software que pode abstrair diferentes aceleradores e a quarta parte é um conjunto de bibliotecas focadas no domínio , como Matlab e assim por diante. Essas são as quatro categorias de coisas em oneAPI, mas podemos ir mais fundo e falar sobre os nove elementos de oneAPI. Esses nove elementos são basicamente a nova linguagem que estamos introduzindo chamada Data Parallel C++ e sua biblioteca padrão.

Existem duas bibliotecas de aprendizagem, uma para redes neurais e outra para comunicações. Há a biblioteca que estamos chamando de nível zero que é para abstração de hardware e há quatro bibliotecas focadas no domínio. Estamos fazendo isso de uma maneira muito, muito aberta. As especificações para todos eles já estão abertas e disponíveis. Estamos chamando-os de versão 0.5. Pretendemos chegar ao 1.0 até o final de 2020, e também temos implementações de código aberto de tudo isso. Novamente, nosso objetivo é permitir que as pessoas aproveitem o que já existe. Se um fornecedor de hardware quiser implementar essa linguagem, ele pode pegar o que é de código aberto e executá-lo.

P: Em relação a algoritmos e implementação, como isso funciona?

O que estamos fornecendo são as primitivas que os algoritmos usariam: as primitivas matemáticas subjacentes e as primitivas de comunicação. Normalmente, a inovação do algoritmo está acontecendo em um nível mais alto do que isso, onde eles não estão realmente refazendo a matemática fundamental, matemática de matriz, matemática de convolução e assim por diante. Trata-se de descobrir novas maneiras de usar essa matemática e novas maneiras de usar os padrões de comunicação. Nosso objetivo realmente é fornecer o primitivo, o nível zero, para que outros possam inovar em cima dele.

P: Como funciona em nível de hardware?

Se você é um fornecedor de hardware, vamos pegar uma matriz de IA, alguém construindo um AI ASIC, por exemplo – há duas maneiras para esse fornecedor de hardware “conectar” e alavancar o ecossistema de IA. Uma seria fornecer essa interface de hardware de baixo nível que estamos chamando de nível zero, e se eles fornecerem sua versão de nível zero usando a API padrão, eles podem aproveitar o código aberto se quiserem e, em seguida, todas as camadas de software acima pode alavancar isso automaticamente.

Isso pode ser difícil para ASICs focados em segmentos, para fornecer toda a generalidade do nível zero. Então, como alternativa a isso, eles também podem fornecer os kernels matemáticos e kernels de comunicação que estão em nosso domínio e bibliotecas de aprendizado profundo, e então faremos o trabalho de “encaixar” essas bibliotecas nas estruturas de nível superior, então eles obteriam isso automaticamente.

P: Você mencionou que a versão que você tem agora é designada 0.5, e a especificação completa deve estar pronta até o final de 2020.

Portanto, há duas partes em nossa iniciativa oneAPI. Uma é a parte da indústria e a outra são os produtos Intel. A especificação do setor está em 0,5 e, por volta do meio do ano, gostaríamos de chegar a 1,0. Paralelamente a isso, a Intel está construindo um conjunto de produtos, e os produtos que a Intel está construindo estão hoje em beta e implementam a especificação 0.5. Até o final do ano, gostaríamos de chegar a um produto 1.0.

O produto da Intel vai além dos nove elementos de oneAPI porque, além dos elementos básicos de programação que fornecemos, também queremos fornecer as coisas que os programadores realmente precisam, como depuradores, analisadores e ferramentas de compatibilidade para que eles migrem de linguagens existentes para o Data Linguagem paralela C++.

P: Quão difícil é para o desenvolvedor fazer a transição? O ambiente mais amplo é semelhante ao que eles usam há anos?

Sim, é muito semelhante. Deixe-me descrever um pouco o Data Parallel C++ porque isso é uma grande parte do que estamos fazendo. DPC++ é três coisas. Ele se baseia na linguagem C++ padrão internacional ISO. Existe um grupo chamado Khronos que define o padrão chamado SYCL, e o SYCL está em camadas sobre o C++. Pegamos SYCL e adicionamos extensões em cima de SYCL. A maneira como estamos construindo o Data Parallel C++, na verdade é apenas C++ com extensões, que é o que SYCL é.

Qualquer compilador C++ pode compilá-lo. A beleza do DPC++ é que qualquer compilador pode compilá-lo, apenas um compilador experiente pode aproveitar o que está nessa linguagem e gerar código acelerador. A maneira como estamos conduzindo essa linguagem, estamos fazendo isso muito, muito abertamente, então todas as nossas discussões sobre Data Parallel C++ estão acontecendo com o comitê SYCL. As implementações são de código aberto, todas as extensões já foram publicadas e estamos trabalhando com muito, muito cuidado para garantir que tenhamos um bom caminho para os futuros padrões SYCL. Olhando para daqui a 5-10 anos, um caminho para o ISO C++ também.

P: Em relação aos compiladores e à migração para DPC++, a curva de aprendizado não deve ser um grande problema?

Sim, depende de onde você está começando, é claro. Para um programador C++, a curva de aprendizado seria muito pequena. Para um programador C, você teria que superar o obstáculo de aprender C++, mas isso é tudo. É muito familiar C++. Para um programador acostumado a linguagens como OpenCL, deve ser muito semelhante.

A outra parte que devo enfatizar é que estamos fazendo o trabalho em código aberto usando a infraestrutura LLVM. Todo o nosso código já está aberto, há um repositório Intel GitHub onde você pode ir e ver a implementação da linguagem, até mesmo baixar um compilador de código aberto. Todas as ferramentas da Intel, nossas ofertas de produtos que são beta também estão disponíveis gratuitamente para qualquer pessoa jogar e baixar. Também temos uma nuvem de desenvolvedor disponível, onde as pessoas não precisam baixar ou instalar nada, podem apenas escrever o código e começar a usar todas as ferramentas que falamos.

P: C++ tem desempenho e é relativamente simples, mas todos sabemos que está ficando velho, o desenvolvimento é lento, há muitos interessados, então eles estão deixando tudo mais lento. Isso obviamente não seria o caso do DPC++. Você teria iterações e atualizações muito mais rápidas?

Acho que você atingiu um ponto muito, muito importante para nós, que é a evolução rápida que não é desacelerada pelos padrões. Então, queremos fazer nossas discussões abertamente com o padrão, então há uma maneira de entrar nos padrões, mas também queremos fazê-lo rapidamente.

As linguagens funcionam melhor quando são coprojetadas por seus usuários e implementadores, à medida que as arquiteturas evoluem. Nosso objetivo é um design de código iterativo realmente rápido, onde estamos praticando as coisas, encontrando a melhor maneira de fazer as coisas e tornando-as padrão. Então, absolutamente, a iteração rápida é um grande objetivo.

P: Uma pergunta que foi levantada por alguns de meus colegas (você provavelmente pode entender que eles estão um pouco preocupados com a abertura com qualquer coisa vinda de uma grande corporação): o DPC++ sempre permanecerá aberto a todos os usuários e fornecedores?

Absolutamente! A especificação é feita com uma licença Creative Commons. Qualquer um pode usar a especificação, pegá-la e bifurcá-la, se quiser, e evoluí-la. Quero enfatizar que nem todos os elementos de oneAPI são de código aberto, mas estamos no caminho de tornar quase todos os elementos de código aberto. Tudo isso, qualquer um pode pegar e aproveitar - está disponível para implementação.

A Codeplay, que é uma empresa do Reino Unido, anunciou uma implementação da Nvidia do DPC++, e estamos realmente incentivando todos os fornecedores de hardware e software a fazer sua porta. Estamos em um ponto único no setor em que os aceleradores estão se tornando comuns para vários fornecedores. Quando isso acontece na história, quando há apenas um provedor, a linguagem deles domina. A indústria de software exige uma solução padrão e vários fornecedores.

O que estamos tentando fazer aqui é o que fizemos cerca de duas décadas e meia atrás com o OpenMP, onde havia várias linguagens paralelas, mas nenhuma realmente dominante. Pegamos tudo isso e unificamos em um padrão que agora, 25 anos depois, é a forma de programar para HPC.

P: Seria correto dizer que o DPC++ verá muita evolução nos próximos anos? E quanto aos tensores, e quanto ao novo hardware saindo?

Sim, absolutamente, você está certo. Temos que evoluir a linguagem para suportar o novo hardware que está sendo lançado. Esse é o objetivo de uma iteração mais rápida. Outro ponto que quero enfatizar é que estamos projetando o Data Parallel C++ para que você também possa conectar extensões específicas da arquitetura, se desejar.

Portanto, embora seja uma linguagem padrão que queremos executar em várias arquiteturas, também percebemos que, às vezes, um público, um público muito importante, precisa do máximo desempenho possível. Eles podem querer mergulhar em programação de nível muito baixo que não será necessariamente portátil para arquitetura. Estamos construindo extensões e mecanismos para que você possa ter extensões para tensores e assim por diante, que seriam específicos da arquitetura.

P: Quanto controle sobre o código gerado para o hardware um desenvolvedor pode ter? Quanto controle eles podem ter sobre o gerenciamento de memória entre o sistema e vários aceleradores?

Estamos pegando emprestado o conceito de buffers do SYCL, que dá um controle de memória muito explícito ao usuário, mas, além disso, também estamos adicionando a noção de memória unificada . Nosso objetivo é permitir ao programador um nível de controle que ele precisa, não apenas para gerenciar memória, mas para gerar código rápido. Algumas das extensões que estamos adicionando ao SYCL são coisas como subgrupos, reduções, pipes e assim por diante. Isso permitirá que você gere um código muito melhor para diferentes arquiteturas.

P: Um ponto interessante é a distribuição oneAPI para Python — a Intel listou especificamente NumPy, SciPy, SciKit Learn. Estou curioso sobre o ganho de desempenho e os benefícios de produtividade que podem ser desbloqueados por meio do oneAPI. Você tem alguma métrica sobre isso?

Essa é uma excelente pergunta. Estamos apoiando esse ecossistema. Por que Python iria querer usar um acelerador? É para obter desempenho de suas bibliotecas de matemática, bibliotecas de análise. O que estamos fazendo é “encanar” NumPy, SciPy, SciKit Learn, etc., para que possamos obter um bom desempenho aproveitando as bibliotecas que temos em cima dele. A implementação padrão de NumPy, SciPy, SciKit Learn e assim por diante, em comparação com aquela que está devidamente conectada com pacotes nativos otimizados, pode obter ganhos muito, muito grandes. Vimos ganhos na ordem de 200x, 300x, etc.

Nosso objetivo com o Python é que queremos chegar a uma fração razoável, dentro de 2x, talvez dentro de 80% do desempenho do código nativo. O estado da arte hoje é que você está frequentemente em 10x ou mais. Queremos realmente preencher essa lacuna, canalizando todas as tarefas de alto desempenho para que você fique dentro de um fator de 2 e, na verdade, muito mais alto do que isso.

P: De que tipos de hardware estamos falando? Os desenvolvedores poderiam desbloquear esse potencial em uma estação de trabalho comum ou seria necessário algo um pouco mais poderoso?

Não, estaria em todos os lugares. Se você pensar de onde vem o ganho, então entenderá. As bibliotecas normais do Python não estão usando nenhum dos recursos de virtualização nas CPUs. Eles não estão usando nenhum dos recursos de vários núcleos nas CPUs. Eles não são otimizados, o sistema de memória e tudo o que não é otimizado. Então, tudo se resume a uma multiplicação de matrizes escrita por um programador ingênuo e compilada por um compilador sem qualquer otimização, e então comparar com o que um especialista escreve em código assembly. Você pode ver ganhos multi-100x quando compara esses dois, e no mundo Python, essencialmente, é isso que está acontecendo.

Os interpretadores Python e as bibliotecas padrão são tão de alto nível que o código com o qual você acaba se torna um código muito, muito ingênuo. Quando você o canaliza corretamente com bibliotecas otimizadas, obtém esses enormes ganhos. Um laptop já tem de dois a seis ou oito núcleos de CPU, eles são multithread e têm recursos de vetorização bastante decentes, talvez 256, talvez 512. Portanto, há muito desempenho em laptops e estações de trabalho. Quando você escala isso para GPUs, assim que tiver gráficos disponíveis, poderá imaginar de onde vêm os ganhos.

Se você observar nossos gráficos integrados, eles também estão ficando muito poderosos. Tenho certeza que você já viu o Ice Lake Gen 11, onde os gráficos integrados são significativamente melhores que a geração anterior. Você pode ver de onde viriam os benefícios, mesmo em laptops.

P: E quanto à disponibilidade do DevCloud? Se bem me lembro, é gratuito para todos no momento, mas continuará assim depois que você for ouro no ano que vem?

Esta é uma boa pergunta. Neste ponto, vou ser honesto, não sei a resposta. Nossa intenção neste momento é que seja livre para sempre. É para desenvolvimento, para brincar, e há muita potência lá, para que as pessoas possam realmente fazer suas corridas.

P: Então, você não se importaria se pedíssemos a alguns milhares de desenvolvedores para tentar?

Ah, absolutamente não. Adoraríamos que isso acontecesse!

Posso resumir o que estamos tentando fazer. Primeiro, estamos muito, muito empolgados com a oneAPI. É hora de uma solução de vários fornecedores decolar, já que existem vários fornecedores disponíveis no mercado agora. Se você der uma olhada em nossa linha de processadores, não apenas as GPUs que estão chegando, GPUs integradas cada vez mais poderosas, e nosso roteiro de FPGA, este é um momento emocionante para construir um padrão para tudo isso. Nosso objetivo é produtividade, desempenho e infraestrutura do setor para que você possa desenvolver.

Quanto aos três públicos sobre os quais falei, os desenvolvedores de aplicativos podem alavancar as coisas facilmente, pois já estão disponíveis. Os fornecedores de hardware podem tirar proveito da pilha de software e conectar um novo hardware, enquanto os fornecedores de ferramentas e idiomas podem usá-lo facilmente. A Intel não pode construir todas as linguagens e todas as ferramentas do mundo, então é uma infraestrutura de código aberto que outros podem aproveitar e construir com muita facilidade.