core.async and 10,000 processes for animation - what is the actual benefit in this scenario?

Question

As we know - core.async uses CSP and is similar to goroutines from go-lang. Now for a scenario like select and alt this makes a lot of sense.

David Nolen has done an amazing demo here showing core.async in Clojure at work in animation in ClojureScript.

Yet I can replicate a similar functionality with a simple for loop. You can see a demo here.

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

My question is What is the actual benefit of core.async in the '10,000 processes animation scenario'?

Windshield

I think that this is a loop with 10000 iterations instead of 10000 "pseudo"-threads that can contain their own logic, that's to say this code don't represent 10000 processes – Victorious

Answer 1

The purpose of the demo is to demonstrate achieving concurrency in ClojureScript with core.async. The big wins are in writing all threads in a standard, sequential fashion, without needing to break them apart into callbacks or manage the interleaving by hand, and in the illusion of blocking on channels (including timeout channels; by blocking, a go yields control to other concurrent gos). Of course there is still no parallelism, but this is a completely orthogonal concept¹; using threads in GUI apps was a useful technique long before multicore CPUs became commonplace.

The resulting code makes things like refresh rate and rate of update generation immediately apparent. You could probably come close in clarity with for loops and setTimeout in this particular case, because all the update-generating gos do the same thing, but launching multiple gos to do completely different things would be equally straightforward.

---

¹ See for example Parallelism /= Concurrency by Simon Marlowe or Parallelism is not concurrency by Robert Harper for an extended discussion of this point.

Putrefy

Even though I knew the answer all that excellent background info makes yours a great read! – Yoong

Answer 2

As you probably know that javascript is single threaded and if you use core.async in terms of "actual execution/operations" you won't get much benefit, but when your loop based code is compared to the core.async code in a runtime environment which utilizes all the CPU cores (like JVM) then you will see the performance benefit of async code.

So, basically if you have some pure algorithmic code (without depedency on runtime enviroment features, like DOM etc) that you have written using core.async then you can easily run the same code in browser OR on your back-end multicore CPU and you will get to use all the CPU cores. This is somewhat on the lines of separating the "denoational semantics" and "operational semantics" of your code.

Cranberry