¿Qué operaciones deberían ser multiprocess?

Me pregunto qué operaciones de juego deberían ser multiprocess y cuáles siempre deberían ejecutarse en el hilo principal.

Las operaciones más caras que pude encontrar son:

  • cargando un nivel
  • carga de resources (para cada nivel o en la initialization del juego)
  • actualizando el mundo del juego (clima, líquidos, reacciones en cadena, muchas entidades pequeñas, etc.)
  • descarga desde el server del juego (files de nivel, resources personalizados, salvaciones de jugadores, estados de objects, etc.)
  • methods pesados ​​ocasionales (capturas de pantalla grandes, cálculos por píxel, actualización mundial completa)

¿Cuál de esas operaciones debería estar enhebrada y cuál no? ¿Cuál de ellos se puede enhebrar de manera más efectiva usando tantos hilos como soporte el host?

¿O es mejor dividir algunas de estas operaciones en bloques y ejecutar cada fotogtwig, poco a poco, sin enhebrar y sin provocar la pérdida de fotogtwigs?

Enhebrar implica concurrency. Piensa en un flujo lógico. ¿Qué le gustaría que ocurriera en Parlel y qué acciones solo deberían ocurrir DESPUÉS de que ocurra algo?

La architecture moderna de la computadora se beneficia de la computación paralela. Ya sea en núcleos de CPU o la GPU.

En mi humilde opinión :

  • No sé si el uso del disco multiprocess mejora mucho el performance y los times de carga (por favor, intente y avíseme: D)

  • Por otro lado, el uso de datos de Internet debe ser absolutamente paralelo. Uno no depende del otro (mucho;))

  • "actualizando el mundo del juego", aquí es donde brilla el paralelismo. Como dije antes, la computación paralela es mejor
  • "methods pesados ​​ocasionales" mismo. A veces puede que desee distribuir el cálculo difícil entre un par de cuadros si puede. No siempre es necesario mantener todo tan rápido como el FPS

Todas las operaciones que se realizan a través de un gran set de datos, con cada operación trabajando independientemente una de la otra, se beneficiarán de la paralelización. Aquí hay algunos ejemplos comunes de tales tareas:

  • Comprobación de colisión
  • Pathfinding
  • Restricción de restricciones
  • Simulación de partículas
  • Interpolación de pose conjunta

Algunas tareas, como la búsqueda de routes, son más adecuadas para la CPU porque los algorithms como A * implican una gran cantidad de ramificaciones dinámicas. Cuando está realizando simulación de partículas o interpolación de pose conjunta, puede download este trabajo a la GPU porque cada operación es idéntica excepto por los datos.

Realmente depende. Es probable que obtenga el mayor beneficio realizando operaciones sin interdependencia de datos entre sí en paralelo, pero como con cualquier cosa, debe hacer un perfil de antemano (y luego) para asegurarse de get el máximo beneficio de sus esfuerzos.

Por ejemplo, para dar algunos consejos concretos con respecto a uno de sus ejemplos, cargando datos:

Si puede factorizar su carga de resources en trozos independientes, esto puede ser beneficioso. Sin embargo, querrá investigar si ya está o no vinculado al disco. Si la parte más lenta de las operaciones de carga está leyendo desde el disco (más probablemente con unidades que no sean SSD, como unidades de disco o medios ópticos), es posible que no mejore su situación. De manera similar, si el destino final de los datos que lee del disco no es independiente, debe verificar que el costo de synchronization de instalar todos los datos cargados no sea un cuello de botella.

En el trabajo todos tenemos SSD en nuestras máquinas de desarrollo, y los contenedores de contenido almacenan sus datos de forma independiente en la memory, por lo que cambiar nuestra cadena de herramientas a un sistema de carga multiprocess tuvo implicaciones de performance significativas (una mejora del 600% en los times de carga). Pero tu kilometraje puede variar.

Se aplican advertencias similares a otras operaciones, como las actualizaciones lógicas del juego. Si puede organizar el problema en trozos discretos de computación que no dependen entre sí, probablemente pueda ver algún beneficio de un model concurrente. Pero si tiene que emplear muchos lockings u otras primitivas de synchronization de subprocesss, es probable que esté intentando paralelizar la parte de serie de la tarea e introducirá más sobrecarga que la que eliminará.

Desea acercarse a la concurrency a gran escala, no a la pequeña. Considere dividir las operaciones en varias tareas simultáneas en la escala de "cargar datos" y "actualizaciones de juegos por cuadro". En general, mirar la escala de "esta gran function de captura de pantalla" es demasiado pequeño para ser útil, por lo tanto, su categoría de "método pesado ocasional" no es muy beneficioso. Las capturas de pantalla son intrínsecamente seriales, excepto por la porción real de disco IO (tratadas anteriormente en nuestra discusión sobre la carga), las operaciones por píxel ya se manejan mejor con la GPU, y no creo que una "actualización mundial completa" sea una "ocasional método pesado ", sino más bien un sinónimo de lo que se discutió anteriormente sobre la actualización del mundo del juego.