On 21 April 2010 00:43, Tom M <letter...@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 <cber...@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 <kimages...@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 > kimages...@kde.org > https://mail.kde.org/mailman/listinfo/kimageshop > _______________________________________________ > Bf-committers mailing list > Bf-committers@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. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
