> 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 <yzhang1...@gmail.com> 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@gnome.org> 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@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
