[Bf-committers] Fwd: Lookup table and float to int conversion and performance

[(Ry)akiotakis (An)tonis]

On 21 April 2010 00:43, Tom M <letterrip at gmail.com> wrote:
> Hi all this might be of general interest to render, composite, and
> paint and other tools in blender so thought I'd forward it,
>
> LetterRip
>
>
> ---------- Forwarded message ----------
> From: Cyrille Berger <cberger at cberger.net>
> Date: Tue, Apr 20, 2010 at 1:31 PM
> Subject: Lookup table and float to int conversion and performance
> To: Krita's developers and users mailing list <kimageshop at kde.org>
>
>
> Hello,
>
> Since pippin has been poking us on irc on using lookup table with floats, I
> wrote a class that do exactly that, code is in [1]. I did a few tests, and I
> get a 4 times improvement on computation of sinus, and 2.5 times improvement
> on computation of sqrt.
>
> An other fact with floating point that have come to my attention recently is
> that conversion to integer is painfully slow, for more details see [2]. And
> using a lookup table is a possible solution see [3] and [4] for what gegl
> people did. Using the floating point lookup table, I noticed 19 times
> improvement on float->uint8, and 1.22 times improvement on float->uint32. But
> more interestingly for our case is the suggestion by [2] to use the 'lrintf'
> function, which is part of the C99 standard, this function gives 44 times
> improvement on float->uint8 and 2.5 times on float->uint32, of course it is
> not totally a replacement for cast since it is a round function, but I think
> in most of our uses, it is good enough. Also 'lrintf' is not available under
> MSVC, so we will probably have to wrap it to be portable to Windows (most
> likely in KoColorSpaceMaths).
>
> It is worth to note that there is an even faster way, but it involves
> assembly, and I am not sure the gain is worth the pain, not counting that it
> is assuming that the FPU is in a good state, which is generally the case, but
> not guaranteed.
>
> The conclusion I take from this is that we need to be careful in conversion
> from float to integer, check when it happen, and only do it when it is
> absolutely needed. And for 2.3, I intend to make the color spaces use
> 'lrintf', and start using the lut [1].
>
> [1] http://bitbucket.org/cyrille/lut
> [2] http://www.mega-nerd.com/FPcast/
> [3] http://www.gimpusers.com/forums/gegl-developer/227-speeding-up-GEGL-
> operations-in-GIMP.html
> [4] http://mysite.verizon.net/spitzak/conversion/sketches_0265.pdf
> --
> Cyrille Berger
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

Very interesting...like everyone I like speed of course but look-up
tables will be a trade-off between accuracy and speed, something not
always desirable. I would surely favor an assembly solution since most
modern processors have explicit functions for sqrt, sin and explicit
float->int conversion if I'm not mistaken. However it -would- require
a bit of pain (= a bit of gain of course!) and maybe more compile
targets for specific processors or dynamic library support. Ouch! I
think that gcc's math library already supports fast arithmetic if you
pass a certain define or argument on compilation.