Based on [Chandra, Stockmeyer 1976], we now reduce the computations with large time and small space to parallel ones (PPM implemented by sorting networks) with large space and small time, and vice versa.
Suppose Professor has in his office a program (for a Small Machine with linear space and exponential time) solving the next exam problems. You break into his office shortly before the test and get the tape. Your time is very limited, insufficient to run the program - but wait! - also in the office you find the password that gains you access to a really Big Machine, one with essentially unlimited space resources (exponential number of parallel processors, memory, etc.). How can you, the devious student, exploit in small time this vast resource to solve the exam?
Generate simultaneously all possible configurations of the Small
Machine with linear memory space, each as a separate process. There will be
of these configurations/processes, as there are 
possible graphs with n nodes and 
edges. Each configuration/process x
computes a pointer 
, where x and 
are successive configurations
of Professor's Small Machine. Now, each process gets a copy of its
successor's successor pointer: 
leads to 
. Next, the
single step pointers are erased and the procedure repeats for the 4-step
pointers, 8-step pointers, etc.
If the Professor's Small Machine halts, then it cannot repeat a configuration
and must stabilize in time <M. So, our pointer-compressing procedure will
take at most 
steps, which is only P-time. Once it is
complete, we need only take the input configuration for the test, and it will
have a pointer to the answer configuration. The volume (time 
space) of computation is still vast. There is no way known to reduce volume to
a polynomial, but you see how we can trade space for time.
Consider now a large array M of interacting automata running in parallel for a P-time.
We will compute M's output (in the central automaton O)
assuming the computation time n (i.e. the depth of the graph) is small.
Each node can be described by a triplet (i,t,s), where i is the position of
the automaton; s its state; t the time. The length of this triplet is
small: 
; 
. How long i's may we need? An
automaton can only be relevant if it has time to propagate its information to
O, i.e. is 
links away from it. There are only 
of those. So:
.
We therefore can store each event in a small space. But it doesn't help if we need to store a large number of events. To know how many events we need to store we consider the Pebble Game with the following rules: The goal is to pebble (put a pebble in) a marked node O of a digraph; one can only pebble a node if all its parents are pebbled; there are k pebbles, they can be removed and reused.
Note that input nodes have no parents and can always be pebbled. You can win
with 
(d: degree of the graph; n: its depth). The proof is by
induction. Suppose you can pebble any node at level 
with 
pebbles. Then you can pebble any node at level t+1 with 
pebbles. You just pebble each of the node's parents, leave a
pebble there and reuse the rest of the pebbles for the next parent. Finally you
put a pebble in the node itself. However, the time needed to pebble this graph
may be large (you may have to traverse all descending paths).
Pebbling a node corresponds to computing an event in our diagram. Each event
can be computed once its parents' are. k is actually the number of events we
may have to store simultaneously. Since we can pebble the graph with 3n
pebbles we can solve the problem in space 
. We transformed
large space, small time into small space, large time.
But the volume (space
time) is still large.