[gst-devel] 0.9 proposals

[Martin Soto]

On Thu, 2004-12-02 at 10:44 -0800, David Schleef wrote:
> On Thu, Dec 02, 2004 at 03:39:55PM +0100, Martin Soto wrote:
> > What my experience so far tells me, is that an intermediate solution may
> > be the answer. This solution would use a mixture of threads and
> > cothreads to achieve an optimum, depending on a number of factors, like
> > whether you are in an SMP machine, how efficient the available thread
> > and cothread implementations are (absolutely and with respect to each
> > other), which latency requirements you have, and, even, whether the
> > particular elements in your pipeline can or cannot avoid blocking.
> 
> That's an intermediate solution?

Yeah, it lies in some middle point between "threads only" and "no
threads at all".

> One of the goals is to decrease the complexity of the core, so that
> it's more approachable by more people.  Using two threading models
> simultaneously doesn't seem to be the right direction.

So, you want to reduce the complexity of the core at the cost of
increasing the complexity of almost every element. There is one core,
but there are a lot of elements. I would rather put the complexity in
the core and try to hide (encapsulate, abstract) it as best as I could.
But that's probably only me.

Anyway, what I'm proposing is to extend and improve the scheduler API in
such a way that these models can be implemented in a clean, properly
encapsulated way. If I later decide to implement an scheduler that
combines five different threading models for the amazement and
bewilderment of the general population, that's my problem, but as long
as the scheduling interface is well specified, no one else has to worry.

I believe that using cothreads can bring us benefits, but the cothreads
based solution doesn't even need to be the standard one for GStreamer.

> > A first comment: I know that speaking of a mixture of threads and
> > cothreads makes some people here shiver. This combination used to cause
> > lots of problems before, at least under Linux. Well, I wrote a Pth
> > implementation of GStreamer's cothread API, and I'm happily using it
> > right now with Seamless (which is certainly threaded).  The trick is to
> > use the New Posix Threads Library (NPTL) at the same time.
> 
> The problems with this:
>  - Not everyone uses NPTL.

Those who still rely on LinuxThreads or whatever, can use the pure
kernel thread based scheduler.

>  - Not everyone uses Linux.

Those who don't, will have to implement a scheduler based on whatever
they have at hand. By the way, embedded platform users may appreciate
having the possibility of using cothreads, because they're easier to
implement.

>  - Pth is not nearly as portable and bug-free as one would like.  (Such
>    as native Win32)

Same as before. Those not having Pth will have to resort to some other
solution. The only reason I'm mentioning Pth is because it's there and
it's fairly portable. Nevertheless, implementing the simple task
switching we need can be done in many ways (Pth is actually overkill for
the purpose).

>  - NPTL is (allegedly) faster than Pth.

Really? Let's give it a try. Attached is a small compressed tar file
with two test programs, a Makefile, and a timing script (time-program).
One program switches constantly between two cothreads using Pth. The
other one does basically the same, but using kernel (g)threads. The
timing script runs the program passed as parameter ten times, and prints
a report of the timings (elapsed, system, user). So, here we go:

$ uname -a
Linux masoft 2.6.8 #2 Sun Oct 17 15:15:17 CEST 2004 i686 GNU/Linux
$ ./time-program ./pth-switch
1: 1.42 0.83 0.55
2: 0.88 0.56 0.31
3: 0.79 0.47 0.30
4: 0.79 0.50 0.27
5: 0.78 0.36 0.41
6: 0.78 0.44 0.32
7: 0.78 0.42 0.34
8: 0.78 0.41 0.36
9: 0.78 0.41 0.36
10: 0.78 0.37 0.39
*: 0.86 0.48 0.36
$ ./time-program ./gthread-switch
1: 5.71 0.88 2.18
2: 4.74 0.71 1.84
3: 4.31 0.65 1.69
4: 4.33 0.70 1.64
5: 4.38 0.69 1.67
6: 4.55 0.70 1.62
7: 4.38 0.68 1.75
8: 4.34 0.66 1.64
9: 4.33 0.67 1.62
10: 4.33 0.65 1.68
*: 4.54 0.70 1.73

The test were set up to switch back and forth one million times, that
is, a total of two million switches per program run. The final lines
(with the *) are the mean values. As you can see, we have about a 5-fold
increase in both elapsed and system time when using gthreads. In the Pth
case, user and system time almost add up to elapsed time. In the
gthreads case there's a big difference. Does anyone have a good
explanation for that?

Anyway, I'd be good for people to run the test locally and report their
results. My machine is an Athlon64 3000+.

> Who cares?  Making the gstreamer core faster or slower by a factor
> of two is mostly irrelevant in the grand scheme of things.  I'd
> *much* prefer to have a system that everyone can understand and
> bug fix with an overhead of 6% than a complicated system at 3%.
> The time that I save from fixing gstreamer bugs I will spend on
> liboil, which can have a direct and massive affect on applications.
> We can always optimize later, *once the bottlenecks are known*.

I could say the same. The time I've spent fiddling with malfunctioning
elements and writing a new scheduler because it was impossible for me to
tell what would happen the next time I needed to change my pipeline, I
could have spent actually improving my DVD player. That's why I say we
need a clean, well specified scheduling interface.

[snip]
> > The other necessary change is to add a way for elements to tell the
> > scheduler that they may block.
> 
> Or, tell the scheduler how to perform the blocking, e.g., wait on a
> file descriptor or lock.  These are essentially the only ways to
> block.

Having provisions in the scheduling API for tasks to wait on I/O and
related events would certainly be a great thing. 

M. S.
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cotheads-compare.tar.gz
Type: application/x-compressed-tar
Size: 1283 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20041202/9c1b586a/attachment.bin>