Con el propósito de ser el hilo conductor entre las marcas líderes en desarrollo tecnológico y el ámbito académico, Winpy facilitó una Workstation de alto rendimiento a la Facultad de Ingeniería en Obras civiles de la Universidad Santiago de Chile -USACH-. Es debido a esta colaboración, el equipo de investigadores logró probar distintas configuraciones de hardware bajo condiciones reales de investigación.
Estas fueron sus conclusiones:
En ingeniería solemos no “arreglar lo que no está roto”. Pero ¿qué pasa si lo que “no está roto” nos está frenando silenciosamente? Ahí entra este experimento.
¿Quieres saber cómo se gestó esta colaboración? Lee nuestro blog: Cuando el poder de cómputo se convierte en una barrera: Una colaboración de USACH y Winpy
Cuando lo que “no está roto” sí frena
Chile aprendió a diseñar mirando de frente a los sismos y otras catástrofes. Primero fue el terremoto de Chillán en 1939, luego el de Valdivia en 1960, quienes nos mostraron que la construcción de adobe debía dejarse de lado, “pavimentando” a la primera normativa de construcción en hormigón en 1972, y que ha sido actualizada a medida que otros terremotos suceden, teniendo su última corrección posterior al terremoto del 2010. Pero no todo aprendizaje debe provenir de la prueba (catástrofe) y error (edificios dañados).
En la Ingeniería en Obras Civiles de la Universidad de Santiago de Chile, convertimos ese aprendizaje duro en una metodología bottom-up: primero entendemos el material en laboratorio; con esos datos alimentamos modelos computacionales; y desde ahí proyectamos el comportamiento estructural de vigas, columnas, losas y paredes.
Así cerramos el ciclo: material > modelo > estructura > obra real.
¿La gracia? Aplicamos mecánica computacional avanzada con software científicos y hardware moderno para simular fenómenos complejos (fractura de hormigón, fuego en estructuras de madera, fricción en conectores de madera, etc.).
Este enfoque nos da dos ventajas prácticas:
- Entendemos alcances y límites de cada material para aplicaciones reales y
- Traducimos conocimiento en decisiones de diseño más resilientes.
La barrera actual
Hay poca información técnica local sobre cómo elegir y exprimir hardware para simulación en nuestro medio. Usamos PCs o workstations que funcionan, pero no sabíamos si eran la mejor inversión para nuestras cargas, ni dónde estaban los cuellos de botella (¿CPU? ¿RAM? ¿disco? ¿GPU?).
Además, muchos códigos científicos no documentan bien qué aceleraciones soportan, por lo que muchas veces tenemos que realizar ensayos de prueba y error que se transforman en verdaderos ensayos de dar palos de ciego.
La idea detrás del experimento
La idea es simple: hacer un review de nuestras simulaciones computacionales pero enfocado en hardware: analizar antes de comprar, con pruebas reales y conclusiones prácticas.
Para el banco de pruebas usamos un AMD Threadripper PRO de última generación (familia 7000 WX), plataforma que en una sola CPU llega hasta 96 núcleos / 192 hilos y 8 canales de DDR5, un tope de gama para cargas altamente paralelas.
Hicimos dos pilotos con estudiantes, imitando problemas académicos de investigación:
- Incendio en vivienda de madera (Fire Dynamic Simulator, FDS): Simulamos la evolución térmica y de fuego en una vivienda ligera usando mecánica de fluidos computacional. FDS permite paralelizar con MPI y OpenMP, lo que lo vuelve naturalmente CPU-bound (y poco amigo del GPU, al menos en su línea principal de uso). Esto hace que el rendimiento por núcleo y la escala en hilos importen mucho.
- Fractura en hormigón (FEniCS / DOLFINx): Problemas de propagación de grietas con elementos finitos, acoplados a PETSc y MPI para escalar en múltiples procesos. Hay esfuerzos recientes para usar GPU (CUDA/ROCm, ésta última es la plataforma de cómputo para GPUs de AMD) en FEniCSx vía PETSc y extensiones, pero su adopción aún está en una fase temprana en este tipo de modelos y requiere compilaciones específicas.
¿Cómo se comportó el hardware?
- Velocidad por núcleo manda (en estos casos): en cargas FDS y FEniCS, el salto de “CPU tope de gama” no se tradujo en tiempos individuales radicalmente menores si medimos una sola simulación; la clave estuvo en el rendimiento por núcleo y en la eficiencia de la paralelización.
- Productividad por concurrencia: donde el AMD Threadripper PRO brilló fue en correr muchas simulaciones a la vez sin degradar tiempos por instancia. Pudimos lanzar hasta 8 simulaciones simultáneas y reducir el tiempo total de análisis en torno a 3X versus una workstation típica.
- GPU: aún hay tarea: intentamos activar aceleración GPU, pero los códigos probados (tal como vienen en binarios/precompilados) no la aprovecharon. Esto es consistente con el estado del arte de FDS (MPI/OpenMP sin GPU por defecto) y con el hecho de que, en FEniCSx, la aceleración GPU existe, pero exige stacks y builds avanzados (PETSc con CUDA/HIP, extensiones específicas).
- Memoria RAM: en estas campañas, no vimos peaks de RAM críticos; los cuellos pasaron por las limitaciones de CPU (cuando había outputs densos).
¿Por qué esto es original (y útil) para Chile?
Porque pasamos de “comprar fierros por tincada” a decidir con datos. En vez de simplemente comprar tarjeta más cara, le vamos a responder con gráficos y tiempos de CPU.
Un equipo benchmark como el Threadripper PRO nos permitió perfilar nuestras cargas de trabajo:
- Qué tanto escalamos con núcleos/hilos (¿OMP/MPI rinde?)
- Cuándo conviene más frecuencia por núcleo que más núcleos
- Si vale la pena GPU para nuestro software
- Cómo presupuestar upgrades con argumentos para hablar con proveedores (y pedir exactamente lo que sirve).
Y sí, saber que existe una plataforma de hasta 96 núcleos y 8 canales de DDR5 te cambia el contexto de la conversación, puesto que pasamos a hablar en un mismo idioma.
Los próximos pasos
Metodología de compra basada en evidencia: repetir este benchmarking por familias de problemas (fuego en estructuras, fractura, comportamiento estructural, etc.).
Construir guidelines de compra de hardware ajustadas a la disponibilidad del o los proveedores. Esto es especialmente útil en la formulación proyectos de investigación para optar a financiamiento público.
Explorar GPU donde tenga sentido: priorizar códigos con soporte maduro (p. ej., stacks con PETSc CUDA/HIP en FEniCSx, u otros solvers CFD/CAEs que hoy sí aceleran en GPU) y evaluar ROCm en equipos disponibles.
Divulgar en lenguaje común: publicar recetas reproducibles (qué compilar, cómo lanzar, cómo medir) para que oficinas de cálculo e instituciones públicas repliquen la metodología sin volverse locas con el tuning.
En resumen
- Medir antes de comprar rinde: descubrimos que, en nuestras simulaciones actuales, la velocidad por núcleo y la concurrencia son los factores determinantes.
- Un equipo tope de gama no sólo acelera “una corrida”; multiplica la productividad cuando lanzas muchas.
- GPU es promesa real, pero solamente si el software lo soporta bien.
- Con esta metodología, podremos comunicarnos de mejor manera con los proveedores y planificar upgrades con números, no con tincadas.
Agradecimientos
A la Agencia Nacional de Investigación y Desarrollo (ANID) a través del proyecto Fondecyt Regular 1240989, por financiar esta investigación.