Web lists-archives.com

Re: Use of lrint() in 'gdk-pixbuf/pixops/pixops.c'




> Currently, there are 2 rounding functions in the fall backs, round()
> and rint(), with rint() having the better less biased IEEE
> round-to-even behavior for the 0.5 case.

Is known and it is a problem that the fallbacks for round and rint
are only mostly working?

For example, there is a number strictly less than 0.5 that round will
round to 1.  And there are a large number of large integers that
round will change.

Morten





On Sat, Feb 4, 2017 at 10:59 PM, Yale Zhang <yzhang1985@xxxxxxxxx> wrote:
> I suggest adding a lrintf() fallback to fallback-c89.c too.
>
> Currently, there are 2 rounding functions in the fall backs, round()
> and rint(), with rint() having the better less biased IEEE
> round-to-even behavior for the 0.5 case.
>
> lrintf() is preferable because it can be done in a single instruction
> (round and convert to int) on x86, while (int)round(x) would need 2
> instructions.
>
> I suggest the following implementation of lrintf():
>
> inline int lrintf(float x)
> {
>     // warning: assumes processor's rounding mode is set to nearest int
> #if defined(__SSE__) && defined(__GNUC__)
>     // single instruction version that avoids conversion of float to SSE vector
>     int rounded;
>     __asm__ (
>              "cvtss2si %1, %0\n"  // most compilers are smart enough
> to convert this to vcvtss2si to avoid expensive AVX-SSE transition
> penalties
>              : "=r"(rounded)
>              : "x"(x)
>             );
>     return rounded;
> #elif defined(__SSE__)
>     return _mm_cvtss_si32(_mm_set_ss(x));
> #else
>     return rintf(x);
> #endif
> }
>
>
> On Sat, Feb 4, 2017 at 12:17 PM, John Emmas via gtk-devel-list
> <gtk-devel-list@xxxxxxxxx> wrote:
>> On 4 Feb 2017, at 19:44, Emmanuele Bassi wrote:
>>
>>>
>>> Please, file a bug against gdk-pixbuf:
>>>
>>>  https://bugzilla.gnome.org/enter_bug.cgi?product=gdk-pixbuf
>>>
>>> I'd rather have a check at configure-time that looks if we have
>>> lrint() available, and if not, provides a fallback. We used this
>>> approach in GTK+ 3.x, and it makes it easier to remove the code once
>>> we decide to bump the compiler requirements, like we did in GTK+
>>> master.
>>>
>>
>> Thanks Emmanuele - just filed bug #778181
>>
>> John
>> _______________________________________________
>> gtk-devel-list mailing list
>> gtk-devel-list@xxxxxxxxx
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list@xxxxxxxxx
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list