Existe uma biblioteca de otimização não linear restrita, como o IPOPT, que roda em GPUs?

Alguém da minha equipe quer paralelizar o IPOPT. (pelo menos algumas das funções). Não consegui encontrar uma implementação de GPU nem um pacote semelhante. Também não encontrei nada nos documentos deles.

Portanto, a questão é: existe uma alternativa já implementada na GPU? ou pelo menos alguém trabalhando para portá-lo na GPU para que possamos trabalhar juntos?

dr: Minha impressão geral da literatura é que as acelerações são modestas (se existirem). O kernel principal que você verá nesses métodos é um método direto direto (por exemplo, LU esparsa, LDLT esparsa) e os acessos à memória são irregulares; essas características não favorecem o uso de GPUs. Além disso, IPMs paralelos estão em sua infância. Eu ainda suspeito que as pessoas vão trabalhar nas implementações de GPU, mas eu sou cético que muito delas virá. (No entanto, os IPMs de memória distribuída parecem um pouco mais promissores e úteis.)

Algumas pessoas já trabalharam em métodos de ponto interior (IPMs) para GPUs:

• Smith, Gondzio e Hall desenvolveram um IPM para programas lineares (LPs) que alcançou acelerações de 4-10x
• Jung e O'Leary examinam alguns dos kernels de álgebra linear nos IPMs para LPs e veem modulações de velocidade para GPUs em problemas maiores em seu conjunto de testes

Em geral, os trabalhos não comparam seu trabalho aos solucionadores de LP altamente afinados. Jung e O'Leary se comparam ao linprog, que não seria a escolha da maioria dos praticantes, e a impressão que tenho ao escanear o artigo de Smith et al é que um método serial de ponto interior foi escrito do zero. Dado que Hall está muito envolvido nos solucionadores de código-fonte aberto LP, levo esse trabalho um pouco mais a sério. Um dos melhores solucionadores de código-fonte aberto do mercado, o Clp, que Hall mantém, e se eles tivessem usado esse código, ele seria mencionado pelo nome. Por isso, prestaria mais atenção se esses códigos estivessem acelerando solucionadores já altamente ajustados, em vez de comparações seriais únicas que não são de última geração.

Dito isto, o trabalho existente é para LPs e você provavelmente está solicitando um solucionador de programação não linear (PNL), porque é isso que é o IPOPT. Aqui está o que eu sei sobre o caso do solucionador de PNL:

• IPMs paralelos é geralmente desafiador (para o caso LP & SOCP, consulte Elemental ; você usaria algo como a versão SOCP (ou uma versão QP) para um IPM geral
• se sua PNL não possui estrutura óbvia (por exemplo, não é um programa estocástico, não possui estrutura angular de bloco com bordas óbvia, não é um problema de otimização com restrição de PDE em que os pré-condicionantes para o PDE são bem conhecidos) , os melhores métodos de álgebra linear envolvem métodos diretos esparsos (por exemplo, LU, LDLT) com acessos de memória irregulares que normalmente não são adequados para arquiteturas de GPU (como mencionado anteriormente)
• se sua PNL tiver estrutura óbvia, convém usar um algoritmo de pesquisa de linha sem inércia que não exija uma fatoração reveladora de inércia (com base nos trabalhos recentes de Chiang e Zavala ), para que você possa usar pré-condicionantes conhecidos para ajudar resolver o sistema Karush-Kuhn-Tucker
• os melhores métodos de pontos interiores de matriz paralela disponíveis que eu conheço são os de Gondzio ( documento de implementação, artigo teórico ) e de Waechter, et al. ( Documento de visão geral de pontos interiores em larga escala , artigo entrando em mais detalhes sobre a implementação de métodos de pontos interiores em larga escala ); também existem algoritmos de Petra, Zavala et al. que exploram a estrutura ( papel estruturado de otimização não-convexo , complemento de Schur para papel de métodos de pontos interiores ).

A maioria das pesquisas parece estar trabalhando em paralelismo para o caso de memória distribuída (o que é bastante difícil). Há algum trabalho no caso de memória compartilhada para solucionadores de LP e QP, porque esse trabalho o transforma em códigos comerciais (por exemplo, Gurobi, CPLEX, Xpress). O trabalho existente é interessante, mas ainda não parece nada atraente para as GPUs, exceto para aplicativos especiais (por exemplo, aprendizado de máquina, para os quais você pode usar algoritmos diferentes, mais adequados para as GPUs).

Geralmente, a otimização não-linear é difícil de paralelizar porque seu algoritmo de escalonamento é muito seqüencial. As GPUs são mais lentas que as CPUs, portanto, você só obtém uma aceleração se tiver o problema como algo altamente paralelo (ou seja, milhares de threads). Portanto, eu não esperaria muita aceleração (ou qualquer outra, geralmente pode ser mais lenta) colocando o solucionador não-linear na GPU. É mais provável que ninguém tenha feito bem, e a maioria das pessoas não tentaria.

Por outro lado, se suas funções de objetivo e restrição puderem ser calculadas de maneira altamente paralela (ou vetorizada), você poderá obter uma aceleração massiva resolvendo suas funções de objetivo / restrição na GPU. Essa é uma maneira comum de usar GPUs com otimização não linear, pois usa a aceleração de GPU na parte mais difícil (e mais paralela) do código e, portanto, é provavelmente a mais eficiente.

Estou um pouco atrasado para a festa, mas a resposta curta é que sim, é possível paralelizar um método de ponto interior para GPUs, mas se isso é ou não bem-sucedido depende da estrutura do problema. Em termos de software existente, a Optizelle pode fazê-lo. Agarre o ramo de desenvolvimento até que uma nova versão ocorra no futuro próximo.

As situações diferem um pouco, dependendo se o problema original contém ou não igualdades ou desigualdades. Há várias maneiras de fazer isso, mas, na minha opinião, a melhor maneira de fazer isso para problemas com apenas restrições de desigualdades é usar um método inexato de região de confiança, método de Newton combinado com um método primal de ponto interior duplo.

Apenas para desigualdades, o método básico inexato da região de confiança de Newton pode ser encontrado na Otimização Numérica de Nocedal e Wright na página 171 ou nos Métodos de Região de Confiança de Conn, Gould e Toint na página 205. Esse algoritmo pode ser combinado com sucesso com um método primitivo- método de ponto interior duplo usando essencialmente o método de CG truncado modificado da página 890 do artigo Um método de ponto interior para programação não-linear em larga escala de Byrd, Hribar e Nocedal. Pessoalmente, não gosto de como eles configuram seu sistema de pontos internos, então não usaria sua formulação de pontos internos, mas essa é a preferência. NITRO é um bom algoritmo. Quanto aos detalhes internos do ponto, o manual da Optizelle explica como fazer isso em seu manual. Eu provavelmente deveria postar um manual atualizado,

Para o caso de restrições de desigualdade e igualdade, acredito que o melhor algoritmo é combinar o método SQP de etapa composta inexato da região de confiança de Heinkenschoss e Ridzal em um artigo intitulado Método SQP de região de confiança livre de matriz para otimização restrita da igualdade. Basicamente, o processo de aplicação de um método de ponto interior funciona da mesma forma que o caso irrestrito, exceto que a etapa quase normal também precisa ser protegida.

Quanto às oportunidades de paralelização, os algoritmos que referencio acima funcionam bem porque esses algoritmos podem ser implementados sem matriz. Especificamente, a implementação da Optizelle para o problema

$\min\limits_{x\in X}\{ f(x) : g(x)=0, h(x)\geq 0\}$

Requer que o usuário forneça uma implementação para

• $f(x), \nabla f(x), \nabla^2 f(x)\partial x$

• $g(x), g^\prime(x)\partial x, g^\prime(x)^*\partial y, (g^{\prime\prime}(x)\partial x)^* \partial y$

• $h(x), h^\prime(x)\partial x, h^\prime(x)^*\partial y, (h^{\prime\prime}(x)\partial x)^* \partial y$

Não importa de onde vêm essas implementações ou como elas são paralelizadas. Eles podem ser feitos na memória compartilhada, na memória distribuída ou nas GPUs. Isso não importa. O que funciona melhor para um problema específico depende da estrutura. Além disso, exige que o usuário forneça álgebra linear para

• init: Memory allocation and size setting
• copy: y <- x (Shallow. No memory allocation.)
• scal: x <- alpha * x
• axpy: y <- alpha * x + y
• innr: innr <- <x,y>
• zero: x <- 0
• rand: x <- random
• prod: Jordan product, z <- x o y
• id: Identity element, x <- e such that x o e = x
• linv: Jordan product inverse, z <- inv(L(x)) y where L(x) y = x o y
• barr: Barrier function, barr <- barr(x) where x o grad barr(x) = e
• srch: Line search, srch <- argmax {alpha \in Real >= 0 : alpha x + y >= 0} where y > 0
• symm: Symmetrization, x <- symm(x) such that L(symm(x)) is a symmetric operator

Essas operações podem ser realizadas em serial, paralela, memória distribuída, memória compartilhada ou em GPUs. Isso não importa. O que é melhor depende da estrutura do problema.

Finalmente, existem os sistemas lineares e existem três que podem ser fornecidos:

• Pré-condicionador para$\nabla^2 f(x)$
• Pré-condicionador esquerdo para$g^\prime(x)g^\prime(x)^*$
• Pré-condicionador correto para$g^\prime(x)g^\prime(x)^*$

Cada um desses pré-condicionadores pode ser implementado em serial ou paralelo, memória distribuída ou compartilhada ou em GPUs. Basicamente, o primeiro pré-condicionador é o pré-condicionador para o sistema de CG truncado associado aos sistemas de otimização. Os dois últimos pré-condicionadores são usados ​​para as soluções do sistema aumentado associadas ao algoritmo SQP da etapa composta. Em geral, é aqui que você obtém seu maior aumento de desempenho. Imagine se a restrição representasse algum tipo de PDE. Então, o pré-condicionador para corresponde a uma solução PDE direta seguida por uma solução PDE adjunta. Observe que, se fossem quadrados,g ′ ( x ) g ′ ( x ) ∗ ( g ′ ( x ) g ′ ( x ) ∗ ) - 1 = g ′ ( x ) - ∗ g ′ ( x ) - $g$$g^\prime(x)g^\prime(x)^*$$(g^\prime(x)g^\prime(x)^*)^{-1}=g^\prime(x)^{-*}g^\prime(x)^{-1}$. Para um grande número de formulações de PDE, como métodos de diferença finita com integradores de tempo explícitos, essas soluções podem ser muito bem paralelizadas em uma GPU.

Finalmente, os algoritmos do Optizelle trabalham com problemas de cone simétrico, que incluem restrições de cone de segunda ordem e de semidefinido. No entanto, em geral, o cone linear resolve tender a executá-lo. Basicamente, as soluções lineares de cone podem reduzir a viabilidade e a otimização feitas em um sistema realmente compacto que pode ser fatorado por Choleski. Como o Optizelle trabalha com sistemas não lineares, ele realmente não pode fazer isso. Pelo menos eu não sei como. Além disso, existem restrições quanto ao tamanho dos blocos SDP com os quais a Optizelle pode lidar. O operadorlinvacima requer o inverso das matrizes SDP e esse inverso é realmente caro para blocos grandes. Além disso, há uma proteção extra segura que requer uma fatoração de Choleski. Essas fatorações não são realmente paralelas em uma GPU. Pelo menos, não conheço uma implementação que seja paralela. De qualquer forma, a conclusão é que, se for um programa de cone linear, use um solucionador de cone linear como CSDP ou SDPT3.

TLDR; Use Optizelle . É gratuito, de código aberto e licenciado para BSD. Dimensionei para algo como meio bilhão de variáveis ​​e funcionou bem. Eu executei com GPUs e funcionou bem. Se funciona ou não bem com uma GPU, depende se as operações acima são paralelas ou não em uma GPU.