On 2014-08-09 18:26:19 +0100, Kieran Kunhya wrote: > We also use a fork specifically to work around very wasteful > calculations in libswscale during 10-bit chroma conversion that > involve multiplying a pixel by a 2^n value with 32-bit precision and > then shifting that value down by n back to 16-bit precision (achieving > nothing). The fix breaks other codepaths that we don't use but the > performance gain is big enough to warrant a fork.
What is the performance gain? I'm wondering what performance gain is important enough to justify a fork in Debian. Well, not just a fork, just recompiling with static linking can yield a significant improvement. For instance, I could obtain up to a 37% gain with a static link against MPFR. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811133947.ga16...@xvii.vinc17.org
