ecst

ECST

C ++ Experimental y trabajo en progreso 14 Biblioteca de encabezado de sistema de sistema de compilación de tiempo compilar multiproteo multipresado.

Descripción general

El desarrollo exitoso de aplicaciones y juegos complejos en tiempo real requiere un sistema de gestión de entidades flexible y eficiente. A medida que un proyecto se vuelve más intrincado, es fundamental encontrar una forma elegante de componer objetos para evitar la repetición del código, mejorar la modularidad y abrir potentes posibilidades de optimización.

El patrón de arquitectura del sistema de componente de la entidad fue diseñado para lograr los beneficios antes mencionados, separando los datos de la lógica.

• Las entidades pueden estar compuestas de componentes pequeños, reutilizables y genéricos.

• Los componentes se pueden almacenar en áreas de memoria contiguas, mejorando así la localidad de datos y la amabilidad de los caché.

• La lógica de la aplicación se puede paralelizar y abstraer fácilmente de los objetos mismos y sus políticas de almacenamiento.

• El estado de la aplicación se puede serializar y compartir a través de la red con menos esfuerzo.

• Una base de código más modular, genérica y fácilmente probable.

"ECST" se desarrolló como mi proyecto de graduación BCS.

---

Empezando

• Construir instrucciones

• Muestra de código

• Licencia

---

Más información

• Tesis acompañante

• Toboganes

  • Nota: Estas están acompañando a una versión anterior de la biblioteca fue presentada en C ++ ahora 2016

---

Terminología

• Entidades: definido por Adam Martin (ver tesis) como "bloques de construcción conceptuales fundamentales" de un sistema, que representan ob-obos de aplicaciones concretas. No tienen datos o lógica específicos de aplicación.

• Componentes: Tipos pequeños, reutilizables que componen entidades. Nuevamente, citando a Adam Martin en (ver tesis) , un tipo de componente "etiqueta una entidad como poseer un aspecto particular". Los componentes almacenan datos pero no contienen ninguna lógica.

• Sistemas: Proveedores de lógica de implementación para entidades que poseen un conjunto específico de tipos de componentes.

• Paralelismo externo: término utilizado en ECST que define el concepto de ejecutar múltiples sistemas que no dependen entre sí en paralelo. Sus detalles de implementación se analizarán en el Capítulo 10 (ver tesis) . Conceptualmente, se crea un gráfico acíclico dirigido implícito en el tiempo de compilación gracias al conocimiento de las dependencias del sistema. La ejecución del DAG implícito es manejada por un tipo de programador del sistema especificado durante la definición de configuración.

• Paralelismo interno: otro que ejecuta sistemas separados en paralelo, ECST admite dividir un solo sistema en múltiples subtareas, que se pueden ejecutar en hilos separados. Muchos sistemas, como los que representan computaciones funcionalmente puras, no contienen efectos secundarios que modifican su propio estado o que definen las interacciones entre las entidades suscritas: estos son ejemplos principales de cálculos "vergonzosamente paralelos".

---

Preguntas frecuentes

• "¿Dónde puedo encontrar documentación para la API?"

  • Ver número #10.

• "¿Podemos tener componentes que no sean construibles por defecto?"

  • Esto ha surgido antes en el pasado. La respuesta es no - ver número 8.

• "Estoy tratando de leer/escribir hacia/desde mi componente, pero estoy recibiendo un error de compilación. ¿Qué está pasando? "

  • Los sistemas necesitan saber en el tiempo de compilación a qué tipos de componentes accederán y cómo (acceso de solo lectura o escritura) . Esto debe especificarse al definir las firmas del sistema . Consulte el número 4 para obtener más información.

• "¿Es posible iterar sobre los componentes unidos a las entidades, sin estar dentro de la función de proceso de un sistema?"

  • Ver número #9.

• "¿Cómo controlar si mi sistema se ejecuta en paralelo o como un solo hilo? "

  • El paralelismo interno de todo el contexto debe habilitarse llamando a tOmt_inner_parallelism () para permitir que los sistemas se dividan en múltiples subcartas . Las estrategias de paralelismo interno se pueden personalizar y componerse en tiempo de compilación para sistemas particulares, durante la definición de firma del sistema .

• "¿Cuál es la diferencia entre hacer que mi sistema de un solo hilo vs desactivante paralelismo interno?"

  • Deshabilitar el paralelismo interno evita que todos los sistemas se dividan en múltiples subcartas , independientemente de su estrategia de paralelismo interno. Hacer un sistema de un solo subproceso evita que ese sistema se divida en múltiples subcartas : esto puede ser necesario para los sistemas que mantienen estructuras de datos o que se basan en iterarse sobre todas las entidades en el mismo hilo.