¿Cuánto tiempo debo esperar para que se realice una recolección de basura antes de eliminar un objeto FFI opaco? ¿Es posible acelerarlo de alguna manera?

Question

Considero escribir enlaces de Haskell a una biblioteca de mecánica cuántica escrita en C++ (escribiría un envoltorio C simple) y CUDA. Un cuello de botella importante es siempre la memoria de la GPU utilizada por las piezas de CUDA. En C++, esto se maneja de manera bastante eficiente porque todos los objetos tienen administración de memoria automática, es decir, se borran tan pronto como salen del alcance. También utilizo la semántica de movimiento de C++ 11 para evitar copias, que obviamente no serían necesarias en Haskell de todos modos.

Sin embargo, me preocupa que ya no funcione tan bien cuando los objetos se gestionan a partir de Haskell recogido de basura, y podría ser necesario idear heurísticas para migrar objetos poco utilizados a la memoria del host (que tiende a ser bastante lento). ¿Es razonable este temor o es tan efectiva la recolección de basura de GHC que la mayoría de los objetos desaparecerán casi tan rápido como en C++, incluso cuando el tiempo de ejecución de Haskell no vea que tiene que ser económico en la memoria? ¿Hay algún truco para ayudar o formas de señalar que algunos objetos ocupan demasiada memoria de la GPU y deben eliminarse lo más rápido posible?

Answer 1

incluso cuando el tiempo de ejecución Haskell no ve que tiene que ser económico en la memoria?

Esta es la cuestión: el GHC GC no sabe lo grande que sus objetos extraños, por lo que no ejerce ninguna presión montón, y por lo tanto no se recogen tan pronto como podrían ser.

Puede mitigar esto llamando al performGC manualmente para forzar un GC principal.