Programación multinúcleo para arquitectura de software

febrero 17

Randy habla sobre el problema con la arquitectura de software de múltiples núcleos y cómo resolver este problema a través de la programación de múltiples núcleos.

Casi todos los sistemas de software importantes que se utilizan en la actualidad se crearon inicialmente antes de la llegada de las computadoras de múltiples núcleos. Las computadoras multiprocesador existen desde hace un tiempo, pero no para la computadora común, y muy pocos sistemas de software se adaptaron para aprovecharlas al máximo.

 Más hardware frente a programación de varios núcleos

Why can’t you throw more hardware at it and expect it to run faster? The issue is almost always characterized as “shared resources.” A shared resource is anything that one task, or thread must use without worrying about another task changing it while it is being used. Concepts of synchronization, locking, mutual exclusion or “critical sections” were developed to deal with the issue of safe sharing of common resources.

The traditional mechanisms for creating safe sharing among tasks are called semaphores or queues or events. Used correctly, the multicore programming primitives allow everything from the incrementing of a shared number to a complete database transaction to be done without the corruption that would occur if tasks were not properly sequenced, or “serialized.”

En la era de la CPU única, existía multiproceso o subprocesos múltiples para crear la ilusión de que múltiples tareas ocurrían al mismo tiempo. Cuando las primitivas de sincronización impedían que una tarea progresara, no había problema, porque la CPU única cambiaba a otra tarea que no estaba bloqueada. Los sistemas de software con recursos compartidos no se degradaron demasiado por la sincronización si siempre había algo que hacer la CPU.

Ejemplo | Varios núcleos

Why can’t multiple cores just make this go 2 or 4 times faster? I’ll try to use an analogy to explain it. Imagine a person at a desk with an inbox, a computer, and an outbox. The job is to take the next item from the inbox and read it, enter information from the item into the computer, get a response from the computer, write it down on a form, prepare it for delivery and put it in the outbox. This cycle takes on the average 5 minutes per item, and the boss needs an output of 30 per hour, not the current 12. To solve this problem, the boss puts another person (core) at the same desk and allows the computer to swivel. Getting started, both people reach into the inbox, grab the same item and tear it in two. Starting over, they agree to notify the other before grabbing. Now, they each read their next items and are ready for data entry. Unfortunately, only one can do this at once, so the other waits, turns the monitor around and starts data entry. In the mean time, the first person prepared the response for the outbox, grabbed the next item, and needed to wait a short time for the computer monitor.

 El problema

La buena noticia es que la producción pasó de 12 artículos por hora a 18. La mala noticia es que el jefe todavía necesita 30. Se agrega otra persona al escritorio y la producción pasa de 18 a 22 artículos por hora. La siguiente persona lo lleva a 24. Una persona más lo mueve a 22, ya que esta persona, siendo igualmente hábil en el procesamiento de artículos, en realidad está interfiriendo con el trabajo que ya estaba ocurriendo.

Así sucede, de una manera muy real, con los sistemas de software que tienen más núcleos arrojados sobre ellos. Los primeros ayudan, un poco, pero llegan a un punto en el que el rendimiento se degrada.

La solución

En cambio, si se proporcionara otro escritorio, bandeja de entrada, computadora y bandeja de salida para la segunda persona, la producción casi se duplicaría. Casi, porque se necesitaría algo de tiempo adicional para llenar dos bandejas de entrada y vaciar dos bandejas de salida en lugar de solo una, pero claramente una buena compensación. La solución es más cara, pero se amortiza rápidamente.

Changing a software system to split up the work is not so easy, especially software that is well established and mature. It’s not just a change in algorithms, it’s a change in architecture.

Si realiza una búsqueda en la web de optimización multinúcleo, encontrará artículos sobre caché L2 compartida or matrix processing. Many OS and chip vendors say that they have done the optimization for you, but they don’t say how. Some have proposed programming languages that have parallel processing constructs added to the language. All of these are fine and helpful, but don’t fix an architectural problem any more than it helps the people processing a single inbox to send them to a speed-reading class. Speed-reading is great, but in the absence of a new desk architecture, it has very limited benefit.

Hay muy pocos artículos sobre arquitectura de programación multinúcleo y de sistema, donde se discuten los principales beneficios del rendimiento de todo el sistema. Resulta que solo hay un principio de diseño importante para crear un sistema de software que se amplíe con múltiples núcleos:

Obtenga todos los recursos necesarios para una tarea

El primer paso es mejor si no es bloqueante. La siguiente mejor opción es hacerlo muy granular, lo que significa que una tarea puede tener partes de un recurso mientras que otra tiene partes diferentes.

Realizar la tarea

Step two may be time consuming, but in a correct multicore programming architecture, it is not blocking other tasks. It can execute in parallel. An important principle of step two is that the sum of the time taken for all cores can be much more than the time it would take one CPU, but the wall-clock time is much less because they are done at the same time. For example, if step two takes a single-CPU system 100ms, then twelve tasks would take 1200ms. In a re-architected multi-core system with 4 cores requiring 180ms for step two, 4 parallel cores each performing the task 3 times (twelve tasks) would be done in 540ms. It hasn’t cut the time by 4, but the stage is set for true scaling when even more cores are added.

 Fusionar o reintegrar rápidamente los resultados de la tarea

El tercer paso es difícil, especialmente para un sistema de administración de base de datos, where ACID principles must be followed. Saving transactions safely to disk in a consistent and durable manner requires synchronization around shared resources. The key here is to do as much work beforehand as possible, so that the re-integration is quick. This is probably why step two takes longer. Step two does more work (in parallel) so that the serialized portion is short. It’s a massively worthwhile trade-off.

El truco ahora es tomar software que funcione y rediseñarlo, no solo optimizarlo, para escalado de múltiples núcleos.

Get notified about new RDM updates

Be the first to know about new Raima Database Manager updates when they go live, use cases, industry trends and more.