[vorbis-dev] Parallelism

[Timothy Wayper]

> Because it's trivial to parallelize vorbis effectively for all
> sensible workloads using pmake and the stock encoder. Why burden the
> software when it's still under active development.

Well, what it I want to compress my original Tubular Bells CD, which I
happen to be listening to at the moment, that only has two continuous
tracks, each 20 minutes long? What if I only want to compress one of these
tracks but I have 4 CPU's in my machine? I really don't think your idea of
"sensible workloads" is valid, unless all the music you listen too is in
radio-byte format... Also, if you want wide spread adoption of a feature,
then requesting end users to employ pmake is not a good idea. I can't even
see the average unix hack bothering with this, let alone people running
Windows/MacOS/BeOS etc.

However is forcing every implementation to use MPI a good idea? MPI is great
for a cluster, or when the nodes are running on different CPU's/operating
systems, but it requires complex end-user configuration. My feeling is that
it is a bit heavy-weight for most people; surely the most common case of
parallelism is multiple CPU's within the same machine, which can be handled
with far less overhead using "native" threads and synchronization
primitives? Maybe there should be a very thin abstraction layer to allow
both MPI and "native" implementations? Maybe my impression of MPI is
incorrect though, please correct me if it's easier to use than I think!

On another note entirely, has anyone completed a BeOS port yet? If not, I'm
quite keen to get involved. I've written a reasonably fast MP3 decoder which
runs under MacOS and BeOS for the game we're developing at the moment
(although I'm nervous about patent issues, so I'd much rather use vorbis!),
so I'm somewhat familiar with the issues involved in the port.

Cheers,
Tim W.

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/