core.async y 10.000 procesos para animación: ¿cuál es el beneficio real en este escenario?

Question

Como la conocemos - núcleo.async usos CSP y es similar a gorutinas de go-lang.Ahora para un escenario como seleccionar y alternativo Esto tiene mucho sentido.

David Nolen ha hecho una demostración increíble aquí que muestra core.async en Clojure trabajando en animación en ClojureScript.

Sin embargo, puedo replicar una funcionalidad similar con un bucle for simple.Puedes ver un demostración aquí.

function animationLoop() {
    for (var i =0;i<100;i++) {
        for (var j= 0; j<100;j++) {
            //decision to animate or hold off
            var decisionRange = randomInt(0,10);
            if (decisionRange < 1) {
                var cell = document.getElementById('cell-' + i + j);
                cell.innerHTML = randomInt(0,9);
                cell.setAttribute('class','group' + randomInt(0,5));
            }
        }
    }
}

Mi pregunta es ¿Cuál es el beneficio real de core.async en el 'escenario de animación de 10.000 procesos'?

Answer 1

El propósito de la demostración es demostrar el logro concurrencia en ClojureScript con core.async.Las grandes ventajas están en escribir todos los hilos de forma estándar y secuencial, sin necesidad de dividirlos en devoluciones de llamada o gestionar el entrelazado a mano, y en la ilusión de bloquear canales (incluidos los canales de tiempo de espera;al bloquear, un go cede el control a otros concurrentes gos).Por supuesto que todavía no hay paralelismo, pero este es un concepto completamente ortogonal¹;El uso de subprocesos en aplicaciones GUI era una técnica útil mucho antes de que las CPU multinúcleo se convirtieran en algo común.

El código resultante hace que cosas como la frecuencia de actualización y la frecuencia de generación de actualizaciones sean inmediatamente evidentes.Probablemente puedas acercarte en claridad con for bucles y setTimeout en este caso particular, porque todos los generadores de actualizaciones goHacemos lo mismo, pero lanzando múltiples goHacer cosas completamente diferentes sería igualmente sencillo.

---

¹ ver por ejemplo Paralelismo /= Concurrencia por Simon Marlowe o Paralelismo no es concurrencia por Robert Harper para una discusión extensa sobre este punto.

Answer 2

Como probablemente sepa, JavaScript es de un solo subproceso y si usa core.async en términos de "ejecución/operaciones reales" no obtendrá muchos beneficios, pero cuando su código basado en bucle se compara con el código core.async en un tiempo de ejecución entorno que utiliza todos los núcleos de la CPU (como JVM), verá el beneficio de rendimiento del código asíncrono.

Entonces, básicamente si tienes algo puro algorithmic code (sin depender de las características del entorno de ejecución, como DOM, etc.) que haya escrito usando core.async, podrá ejecutar fácilmente el mismo código en el navegador O en su CPU multinúcleo back-end y podrá utilizar todos los núcleos de la CPU.Esto está en cierto modo en la línea de separar la "semántica denocional" y la "semántica operativa" de su código.