Snap! supports parallelism! The programming environment is full of concurrency, both implicit (e.g. two scripts both start when the green flag is clicked, or when they receive the same broadcast message) and explicit (e.g. the launch block). Let's first explore the explicit kind, then we will play with the implicit kind a bit.

Let's try to use concurrency for what it was meant for: speed!

There are three important models of the machine you should develop:

1. Snap! is like a parent with lots of kids, the parent wants to give the kids equal attention. So if there are 3 things happening at one time, Snap! will rotate among the three of them, giving each of them a chance to do their "thing" (e.g., complete one iteration of a loop). It will choose the same order every time, in a very predictable way. This is known as time-sharing.
2. Snap! has a speed governor so that projects can run at the same speed on different machines. It is obvious why that is important—imagine developing this great Pac Man game on your parent's slow computer and working very hard to get the timing just right so it is not too fast or slow. However, when you share it with others who have faster machines, it runs too fast to play (because the other computers have a faster "heartbeat", the clock rate). So Snap! slows itself down on faster computers so that it always looks like it is running on the same, slow, computer. The reason this is relevant in the discussion of concurrency is that (on the vast majority of computers) Snap! spends a lot of time just sitting there, waiting, so it has lots of idle "cycles" to handle multiple things running at the same time.
3. Snap! actually does NOT make use of more than one core (independent hardware computation unit), it runs everything in one core and time shares any parallel task on the single core. This gives Snap! much more control over its parallelism, since once you decide to use two (or more) physical cores, you can no longer control when (or in what order) the computations will return, and you open up the standard Pandora's box of concurrency problems, like deadlock and race conditions. So your Snap! programs are insulated from these realities, allowing you to have predictable parallelism (usually impossible) at the cost of being able to run really fast and make use of hardware resources.