Re: mulithread rework

Con Kolivas schrieb:
>> Con Kolivas wrote:
> Converting it to strict locking has the effect of performing at
> virtually the same rate of frame encoding, but with much less CPU
> usage. What this means is that no CPU is wasted whatsoever by burning
> in the yield() loopback. The reason we don't get any more encoding
> speed is that as I said previously, it's not CPU limiting that
> prevents further speed gains; it's actually the fact that each
> successive thread depends entirely on the progress of the previous
> thread before it can make any forward progress. This is what I was
> worried about back earlier when I said it didn't sound particularly
> scalable.
 >
> Anyway, for the moment, I don't have any magic bullets on how to speed
> up the encoding. There simply isn't enough work for each thread to do
> before it blocks waiting on the other thread. Unless there was another
> way of parallelising the workloads such that each thread has more work
> to do before blocking, I think you're pretty close to the ceiling of
> the scalability of this approach. I'll look to see if there's anything
> else that can be done, but I'm not optimistic about the chances.
> 
> It was fun playing though :-)

That's good.

Actually there are a few knobs to tune now that it is not burning cycles 
to extract more useful work for the CPUs.

If possible you could try to change when a thread starts working again 
by setting it to use larger sets of macroblocks, i.e. only start when 
the above row has proceeded by k blocks (and not 1 as in current code).
This alone will make things worse but together with setting more threads 
(at least 2x number of cores) I guess there will be enough additional 
work for the CPUs to do.

Anyway it's a small (and I hope worthwhile) change to try and it just 
*could* work :)

bis besser,
Tobias