Improving clarity

Author: erichgess

src/vision/status_quo/barbara_simulates_hydrodynamics.md

@@ -17,7 +17,7 @@ His first attempt to was to emulate a common CFD design pattern: using message p
 This solution worked, but Niklaus had two problems with it. First, it gave him no control over CPU usage so the solution would greedily use all available CPU resources. Second, using messages to communicate solution values between patches did not scale when his team added a new feature (tracer particles) the additional messages caused by this change created so much overhead that parallel processing was no faster than serial. So, Niklaus decided to find a better solution.
 
 ### Solution Path
-To address the first problem: Niklaus would decouple the work that needed to be done (solving each patch) from the workers (threads) this would allow him to more finely control how many resources were used. So, he began looking for a tool in Rust that would meet this design pattern. When he read about `async` and how it allowed the user to define units of work, called tasks, and send those to an executor which would manage the execution of those tasks across a set of workers, he thought he'd found exactly what he needed. Further reading indicate that `tokio` was the runtime of choice for `async` in the community and, so, he began building a new CFD tool with `async` and `tokio`.
+To address the first problem: Niklaus' new design decoupled the work that needed to be done (solving physics equations for each patch in the grid) from the workers (threads), this would allow him to set the number of threads and not use all the CPU resources. So, he began looking for a tool in Rust that would meet this design pattern. When he read about `async` and how it allowed the user to define units of work and send those to an executor which would manage the execution of those tasks across a set of workers, he thought he'd found exactly what he needed. He also thought that the `.await` semantics would give a much better way of coordinating dependencies between patches. Further reading indicated that `tokio` was the runtime of choice for `async` in the community and, so, he began building a new CFD solver with `async` and `tokio`.
 
 As Niklaus began working on his new design with `tokio`, his use of `async` went from a general (from the textbook) use of basic `async` features to a more specific implementation leveraging exactly the features that were most suited for his needs. At first, Niklaus was under a false impression about what `async` executors do. He had assumed that a multi-threaded executor could automatically move the execution of an `async` block to a worker thread. When this turned out to wrong, he went to Stackoverflow and learned that async tasks must be explicitly spawned into a thread pool if they are to be executed on a worker thread. This meant that the algorithm to be parallelized became strongly coupled to both the spawner and the executor. Code that used to cleanly express a physics algorithm now had interspersed references to the task spawner, not only making it harder to understand, but also making it impossible to try different execution strategies, since with Tokio the spawner and executor are the same object (the Tokio runtime). Niklaus felt that a better design for data parallelism would enable better separation of concerns: a group of interdependent compute tasks, and a strategy to execute them in parallel.