>
> Don't the bit reservoir and some other features add inter-frame
> dependencies?
> Perhaps you could distribute 100 frames or so at a time to minimize
> inter-frame
> dependencies (and the overhead of communications latency).
>
The dependencies are quite complex: to encode frame N, you need
to know the size of the bit reservoir, which you dont know until
you've encoded frame N-1. You also need to know the psycho
acoustics for frames N+1,N,N-1 and N-2.
But it is possible to parallelize at the frame level
as Acy suggests: each cpu encodes 100 frames,
but with a 2 frame overlap because of the above problems.
i.e. cpu0: encodes frames 0-99
cpu1: encodes frames 98-199 (and discards frames 98 and 99)
cpu2: encodes frames 198-299 (discards frames 198, 199)
etc...
And each block of 100 frames would have to make sure the bitreservoir was
not used for the first 3 frames.
I agree with several people who pointed out that encoding on
a cluster is really only usefull as an educational exercise.
A more usefull parallelism would have to be obtained at a lower
level. The easiest thing (for a shared memory machine) would be
multithreading all the major loops. Some of the commercial C
compiliers can do this automatically, and I think they work pretty
well on a 2 or 4 way SMP.
Anyone know what GOGO actually multithreaded? I haven't
had time to take a look yet.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
