[Webkit-unassigned] [Bug 74054] fast path to accelerate processing in AudioBus::processWithGainFromMonoStereo
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Dec 12 03:44:37 PST 2011
https://bugs.webkit.org/show_bug.cgi?id=74054
--- Comment #9 from Wei James <james.wei at intel.com> 2011-12-12 03:44:37 PST ---
(In reply to comment #3)
> A side note on a different optimization. It's not necessary to implement this instead of the proposed patch.
>
> With the current patch, we still do (slightly) extra work if needDezipper is true. During the loop, we may get close enough to the target that we don't need to dezipper anymore.
>
> Since the dezippering is just an exponential filter, we can figure exactly how many steps will be needed to get with epsilon of the target value. So compute this value, nConv, and have two loops:
>
> N = min(nConv, framesToProcess);
> for (k = 0; k < N; ++k) {
> <loop with dezippering>
> }
>
> for (k < framesToProcess; ++k) {
> <loop without dezippering>
> }
>
> Assuming I did the math correctly,
>
> nConv = log(eps/abs(g0 - totalDesiredGain))/log(1 - DezipperRate)
> = log(eps)/log(1-DezipperRate)
> - log(abs(g0-totalDesiredGain))/log(1-DezipperRate)
>
> where g0 is the starting gain value at the beginning of the routine. All of the logs are constants except for log(abs(g0-totalDesiredGain)), so the computation of nConv is not too bad. log, however, is not cheap, so it's hard to tell if we would get a net win or not since the processing in the loops is fairly simple. A quick and dirty log approximation might be good enough.
Raymond, I updated the patch to apply your solution.
The test showed that it will get 75% performance gain at most (when nConv == 0). For nConv = framesToProcess (all frames need de-zippering), it will not impact the overall performance.
In the previous comment, I said 2.x performance boost, I checked the test code and found the memory cache impact the test result. So I made some change to avoid memory cache in my test and it also shows the same result.
BTW, in current implementation, the epsilon is a pre-defined value. Should it be a pre-defined value or a percentage of the difference between gain and targetGain? If it is the latter, no log needed.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list