core.async et 10 000 processus pour l'animation - quel est l'avantage réel dans ce scénario ?

Question

Comme nous le savons - core.async les usages Fournisseur de services de chiffrement et est semblable à goroutines depuis aller-lang.Passons maintenant à un scénario comme sélectionner et alt cela a beaucoup de sens.

David Nolen a fait une démo étonnante ici montrant core.async dans Clojure au travail en animation dans ClojureScript.

Pourtant, je peux reproduire une fonctionnalité similaire avec une simple boucle for.Vous pouvez voir un démo ici.

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));
            }
        }
    }
}

Ma question est Quel est l'avantage réel de core.async dans le « scénario d'animation de 10 000 processus » ?

Answer 1

Le but de la démo est de démontrer la réalisation concurrence dans ClojureScript avec core.async.Les grands gains résident dans l'écriture de tous les threads de manière standard et séquentielle, sans avoir besoin de les diviser en rappels ou de gérer l'entrelacement à la main, et dans l'illusion du blocage sur les canaux (y compris les canaux de délai d'attente ;en bloquant, un go cède le contrôle à d'autres concurrents gos).Bien sûr, il n'y a toujours pas parallélisme, mais c'est un concept complètement orthogonal¹;l'utilisation de threads dans les applications GUI était une technique utile bien avant que les processeurs multicœurs ne deviennent monnaie courante.

Le code résultant rend immédiatement apparents des éléments tels que le taux de rafraîchissement et le taux de génération de mises à jour.Vous pourriez probablement vous rapprocher en termes de clarté avec for boucles et setTimeout dans ce cas particulier, car tous les générateurs de mises à jour gofaisons la même chose, mais en lançant plusieurs gofaire des choses complètement différentes serait tout aussi simple.

---

¹ Voir par exemple Parallélisme /= Concurrence par Simon Marlowe ou Le parallélisme n'est pas la concurrence par Robert Harper pour une discussion approfondie sur ce point.

Answer 2

Comme vous le savez probablement, javascript est à thread unique et si vous utilisez core.async en termes d'"exécutions/opérations réelles", vous n'en tirerez pas beaucoup d'avantages, mais lorsque votre code basé sur une boucle est comparé au code core.async dans un runtime environnement qui utilise tous les cœurs de processeur (comme JVM), vous verrez alors les avantages en termes de performances du code asynchrone.

Donc, en gros, si vous avez du pur algorithmic code (sans dépendance aux fonctionnalités de l'environnement d'exécution, comme DOM, etc.) que vous avez écrites en utilisant core.async, vous pouvez alors facilement exécuter le même code dans le navigateur OU sur votre processeur multicœur back-end et vous pourrez utiliser tous les cœurs de processeur.Cela revient quelque peu à séparer la « sémantique dénoationnelle » et la « sémantique opérationnelle » de votre code.