Win32Threads -> PThreads

[Mutant_Fruit]

Hi,

I'm just wondering how switching from Win32Threads to PThreads could increase the speed of encoding. The PThread library (to the best of my knowledge) is just a wrapper around the native Win32 thread functions.

So shouldnt there be a performance penalty (however slight) rather than performance gain?

[foxyshadis]

PThreads aren't implemented on top of Win32 threads; they're on top of something closer to fibers, which are win32's threadless threading (for swapping in your homebrew thread library). The only Win32 primitive that seems to be used are Critical Sections (which are very fast), and other primitives like mutexes, semaphores, and interlocked exchanges are built on top of that (along with some inline assembler). In win32, mutexes and other semaphores are handled by the kernel (kernel transitions are expensive), because they're cross-process, whereas Pthreads has zip zero nada for cross-process threading.

We also have the so-called Metered Section (http://msdn2.microsoft.com/en-us/library/ms810428.aspx), but I've yet to run across it in real code.

[Mutant_Fruit]

Hi,

Thats new to me alright. I thought PThreads were built on top of Win32 threads. Interesting stuff. Thanks for the info.

[Manao]

Anyway, the big speed up that occured recently isn't due to the use of pthreads. It's the new threading method that is to "blame".

[Mutant_Fruit]

Yup, i know that. It's just that i thought that PThreads were built on top of Win32 threads, which meant that you'd be losing some of that performance gain by switching to PThreads.

From the "benchmarks" i saw, it seemed that running 2 threads on build 606 (without PThreads) performed faster than 2 threads on build 610 (with PThreads). But if you used *more* threads on build 610, you would gain higher performance. I thought that this higher performance was due to the new threading model overcoming loss by using pthreads.

Obviously i was wrong ;)

[Manao]

I thought that this higher performance was due to the new threading model overcoming loss by using pthreads.No, whatever the threading library used ( pthreads, win32, ... ), using more threads than CPU will make the encoding faster with the new threading method. That's because the threading method relies on launching the encoding of a new frame in a thread when the reference frame(s) have enough macroblocks already encoded. If you have as much CPU as threads, you'll use all CPUs completely only if all frames take the same time to encode, which is far from being the case. Using more threads allows a better use of all the CPUs, even when frames don't take the same time to encode.

The switch to pthread was made because creating threads with win32 was costing too much on some systems. Haali has put up a patch using the win32 api that avoids the creation of threads, but afaik it has not yet been accepted because it didn't bring any speed up.

[Mutant_Fruit]

No, whatever the threading library used ( pthreads, win32, ... ), using more threads than CPU will make the encoding faster with the new threading method.
Yup, but i thoguht that PThreads were costing more than Win32 threads as the performance seemed to be less when comparing the same number of threads before and after. Thats the bit that confused (and still confuses) me.

The switch to pthread was made because creating threads with win32 was costing too much on some systems. Haali has put up a patch using the win32 api that avoids the creation of threads, but afaik it has not yet been accepted because it didn't bring any speed up.
You're absolutely right, Creating and destroying a large number of threads is costly. Wouldn't creating a threadpool not be the way forward? Maybe that i what Haali's patch was. The idea is something along the lines of:

Create thread that is in a controllable infinite loop.
Set to thread to sleep at the end of each loop until triggered.
When work needs to be done, you pass it to the threadpool like (threadpoolQueueWork(*workitem)).
Threadpool then passes the work into a piece of memory allocated for the sleeping thread.
Threadpool triggers thread to wake up and do piece of work.
Threadpool then sleeps again.

Thus no new threads are created, but threads are reused. If its any use, i could grab a copy of a sample implementation in C which is under the MIT/X11 license, i.e. completely free to use by anyone for any reason.

[Manao]

Haali's patch was using windows' inbuilt thread pool, so that was the idea indeed.

[akupenguin]

Yup, but i thoguht that PThreads were costing more than Win32 threads as the performance seemed to be less when comparing the same number of threads before and after. Thats the bit that confused (and still confuses) me.
Whether or not that's limited to pthreads, it does leave something to be desired. Despite the uneven distribution of time per frame, on linux I get more performance per thread with sliceless, not just more performance total.