¿Existe una biblioteca de optimización no lineal restringida como IPOPT que se ejecuta en GPU?

Alguien en mi equipo quiere paralelizar IPOPT. (al menos algunas de sus funciones). No he podido encontrar una implementación de GPU o un paquete similar. Tampoco he encontrado nada en sus documentos.

Entonces la pregunta es, ¿hay una alternativa ya implementada en la GPU? o al menos alguien trabajando en portarlo a la GPU para que podamos trabajar juntos?

TL; DR: Mi impresión general de la literatura es que las aceleraciones son modestas (si existen). El núcleo principal que verá en estos métodos es un método directo disperso (por ejemplo, LU disperso, LDLT disperso), y los accesos a la memoria son irregulares; Estas características no favorecen el uso de GPU. Además, los IPM paralelos están en su infancia. Todavía sospecho que las personas trabajarán en implementaciones de GPU, pero soy escéptico de que saldrán muchas de ellas. (Sin embargo, los IPM de memoria distribuida parecen un poco más prometedores y útiles).

Algunas personas han trabajado en métodos de punto interior (IPM) para GPU:

• Smith, Gondzio y Hall desarrollaron un IPM para programas lineales (LP) que lograron aceleraciones 4-10x
• Jung y O'Leary observan algunos de los núcleos de álgebra lineal en IPM para LP y ven aceleraciones modestas para GPU en problemas más grandes en su conjunto de pruebas

En general, los documentos no comparan su trabajo con los solucionadores de LP altamente afinados. Jung y O'Leary se comparan con linprog, que no sería la elección de la mayoría de los profesionales, y la impresión que obtengo al escanear el documento de Smith, et al es que un método de punto interior en serie fue escrito desde cero. Dado que Hall está muy involucrado en los solucionadores de LP de código abierto, tomo ese trabajo un poco más en serio. Uno de los mejores solucionadores de LP de código abierto que existen es Clp, que Hall mantiene, y si hubieran usado ese código, se mencionaría por su nombre. Por lo tanto, prestaría más atención si estos códigos estuvieran acelerando los solucionadores ya altamente ajustados, en lugar de las comparaciones en serie únicas que no son lo último en tecnología.

Dicho esto, el trabajo existente es para LP, y probablemente esté solicitando un solucionador de programación no lineal (PNL), porque eso es lo que es IPOPT. Esto es lo que sé sobre el caso de solución de PNL:

• Paralelamente, los IPM generalmente son un desafío (para el caso de LP y SOCP, consulte Elemental ; usaría algo como la versión SOCP (o una versión QP) para un IPM general
• si su PNL no tiene una estructura obvia (p. ej., no es un programa estocástico, no tiene una estructura angular de bloque confinado obvio, no es un problema de optimización restringido por PDE donde los preacondicionadores para PDE son bien conocidos) , los mejores métodos de álgebra lineal implican métodos de dispersión directa (p. ej., LU, LDLT) con accesos irregulares a la memoria que generalmente no son adecuados para arquitecturas de GPU (como se mencionó anteriormente)
• Si su PNL tiene una estructura obvia, querrá utilizar un algoritmo de búsqueda de línea libre de inercia que no requiera una factorización reveladora de inercia (basándose en el trabajo reciente de Chiang y Zavala ), por lo que podría usar preacondicionadores conocidos para ayudar resolver el sistema Karush-Kuhn-Tucker
• Los mejores métodos disponibles de punto interior de matriz paralela que conozco son los de Gondzio ( documento de implementación, documento de teoría ), y de Waechter, et al. ( Documento de resumen de puntos interiores a gran escala , documento que entra en más detalles sobre la implementación de métodos de puntos interiores a gran escala ); También hay algoritmos de Petra, Zavala y otros que explotan la estructura ( papel estructurado de optimización no convexo , complemento de Schur para papel de métodos de punto interior ).

La mayoría de las investigaciones parecen estar trabajando en el paralelismo para el caso de memoria distribuida (que es lo suficientemente difícil). Hay algo de trabajo en el caso de memoria compartida para solucionadores de LP y QP, porque ese trabajo se convierte en códigos comerciales (por ejemplo, Gurobi, CPLEX, Xpress). El trabajo existente es interesante, pero aún no parece haber nada convincente para las GPU, a excepción de las aplicaciones especiales (por ejemplo, aprendizaje automático, para las cuales puede usar diferentes algoritmos más adecuados para GPU).

En general, la optimización no lineal es difícil de paralelizar porque su algoritmo de pasos es muy secuencial. Las GPU son más lentas que las CPU, por lo que solo obtendrá una aceleración si tiene su problema como algo muy paralelo (es decir, miles de subprocesos). Por lo tanto, no esperaría una gran aceleración (o alguna, generalmente podría ser más lenta) al colocar el solucionador no lineal en la GPU. Es muy probable que nadie lo haya hecho bien, y la mayoría de la gente no lo intentaría.

Por otro lado, si sus funciones objetivo y de restricción se pueden calcular de una manera altamente paralela (o vectorizada), puede obtener una aceleración masiva resolviendo sus funciones objetivo / de restricción en la GPU. Esta es una forma común de usar GPU con optimización no lineal, ya que usa la aceleración de GPU en la parte más difícil (y más paralela) del código, y por lo tanto es probablemente la más eficiente.

Llego un poco tarde a la fiesta, pero la respuesta corta es que sí, es posible paralelizar un método de punto interior para GPU, pero si eso es exitoso o no depende de la estructura del problema. En términos de software existente, Optizelle puede hacerlo. Tome la rama de desarrollo hasta que ocurra una nueva versión en el futuro cercano.

Las situaciones difieren ligeramente dependiendo de si el problema original contiene o no igualdades o desigualdades. Hay una variedad de formas de hacer esto, pero, en mi opinión, la mejor manera de hacerlo para problemas con restricciones de desigualdades es usando un método inexacto de la región de confianza, método de Newton combinado con un método primario de doble punto interior.

Solo para las desigualdades, el método Newton de región de confianza inexacto básico se puede encontrar en Nocedal and Wright's Numerical Optimization en la página 171 o en Conn, Gould y Toint's Trust-Region Methods en la página 205. Este algoritmo se puede combinar con éxito con un método primario. método de doble punto interior utilizando esencialmente el método modificado de CG truncado de la página 890 del documento Un método de punto interior para la programación no lineal a gran escala por Byrd, Hribar y Nocedal. Personalmente, no me gusta cómo configuran su sistema de puntos interiores, por lo que no usaría su formulación de puntos interiores, pero esa es la preferencia. NITRO es un buen algoritmo. En cuanto a los detalles del punto interior, el manual de Optizelle explica cómo hacer esto en su manual. Probablemente debería publicar un manual actualizado,

Para el caso con restricciones de desigualdad e igualdad, creo que el mejor algoritmo es combinar el método inexacto de SQP de paso compuesto de región de confianza de Heinkenschoss y Ridzal en un documento titulado Un método de SQP de región de confianza libre de matriz para la optimización restringida de igualdad. Básicamente, el proceso de agregar un método de punto interior funciona más o menos igual que el caso sin restricciones, excepto que el paso cuasinormal también debe protegerse.

En cuanto a las oportunidades de paralelización, los algoritmos a los que me refiero anteriormente funcionan bien porque estos algoritmos pueden implementarse sin matriz. Específicamente, la implementación de Optizelle para el problema

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

Requiere que el usuario proporcione una implementación 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$

No le importa de dónde provienen estas implementaciones o cómo están paralelas. Se pueden hacer en memoria compartida, memoria distribuida o GPU. No importa. Lo que funciona mejor para un problema particular depende de la estructura. Además, requiere que el usuario proporcione álgebra lineal 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

Estas operaciones pueden realizarse en serie, paralelo, memoria distribuida, memoria compartida o en GPU. No importa. Lo mejor depende de la estructura del problema.

Finalmente, están los sistemas lineales y hay tres que se pueden proporcionar:

• $\nabla^2 f(x)$
• $g^\prime(x)g^\prime(x)^*$
• $g^\prime(x)g^\prime(x)^*$

$g$$g^\prime(x)g^\prime(x)^*$$(g^\prime(x)g^\prime(x)^*)^{-1}=g^\prime(x)^{-*}g^\prime(x)^{-1}$

Finalmente, los algoritmos en Optizelle funcionan en problemas de cono simétrico, que incluyen restricciones de cono, de segundo orden y semidefinidas. Sin embargo, en general, las soluciones de cono lineal tenderán a superarlo. Básicamente, las soluciones de cono lineales pueden reducir la viabilidad y la solución de optimización realizadas en un sistema realmente compacto que puede ser factorizado por Choleski. Dado que Optizelle funciona con sistemas no lineales, realmente no puede hacer eso. Al menos, no sé cómo. Además de eso, hay restricciones en el tamaño de los bloques SDP que Optizelle puede manejar. El operadorlinvarriba requiere el inverso de las matrices SDP y ese inverso es realmente costoso para bloques grandes. Además, hay una protección adicional que requiere una factorización Choleski. Estas factorizaciones realmente no se paralelizan bien en una GPU. Al menos, no conozco una implementación que se paralelice bien. De todos modos, la conclusión es que si se trata de un programa de cono lineal, use un solucionador de cono lineal como CSDP o SDPT3.

TLDR; Utiliza Optizelle . Es gratis, de código abierto y con licencia BSD. Lo he ampliado a algo así como medio billón de variables y funcionó bien. Lo ejecuté con GPU y funcionó bien. Si funciona bien o no con una GPU depende de si las operaciones anteriores se paralelan bien o no en una GPU.