[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [PATCH] Replace KisVector2D by Eigen
From:       "Robert Knight" <robertknight () gmail ! com>
Date:       2008-08-26 1:59:27
Message-ID: 13ed09c00808251859w1f12d748ybd4eaa849453bb64 () mail ! gmail ! com
[Download RAW message or body]

> Compiling with -O2 doesn't prevent you from running gdb, -O2 is
> perfectly compatible with -g (generate debug info). There is one case
> when it can interfere with debugging: -O2 will inline many trivial
> functions, so you can't see them in gdb. I don't think this can be
> much of a problem in KDE or KOffice. But e.g. when I debug Eigen
> itself (that is, its unit-tests) I compile without optimization in
> order to see the trivial functions.

There are other problems:

* The apparent order of execution does not match that which you might expect
from looking at the code.  In some cases, the code which is actually
generated 'looks'
very different from the original source (as a result of unrolled
loops, re-ordered blocks, vectorized loops etc.)
so gdb will appear to act very oddly when you step through a function.

* Some local variables will get optimized away so you cannot inspect them

Regards,
Robert.

2008/8/23  <jacob@math.jussieu.fr>:
> Update: Mek on IRC just found out that GCC is already able to
> automatically optimize qAbs -- so that there is no point in providing
> a GCC-specific patch.
>
>
>
> [16:41] <Mek> bjacob: in my gcc with optimizations enabled, the code
> of qAbs produces the exact same non-branching assembly as that of
> std::abs...
> [16:42] <bjacob> Mek: really.... ok, interesting...
> [16:42] <bjacob> didn't know gcc was that clever...
> [16:42] <Mek> hmm... even with -O0 it produces non-branching code
> [16:43] <bjacob> that means there _are_ template specializations
> already, but i didn't see them (they're not in the same fil)
> [16:43] <Mek> no, in a seperate small file without any template stuff,
> with that code, gcc does the right thing already
> [16:43] <bjacob> ?!
> [16:44] <bjacob> with ints or floats ?
> [16:44] <Mek> with ints at least
> [16:44] <bjacob> ah
> [16:44] <bjacob> this one is especially easy
> [16:44] <bjacob> can you check float...
> [16:45] <bjacob> hm... in fact it's going to be the same... it's just
> a bit op after all...
> [16:45] <Mek> for floats with optimizations enabled, the code is the same
> [16:45] <bjacob> ah,interesting
>
> Quoting Girish Ramakrishnan <girish@forwardbias.in>:
>
>> jacob@math.jussieu.fr wrote:
>>> Quoting "Aaron J. Seigo" <aseigo@kde.org>:
>>>
>>>> On Friday 22 August 2008, jacob@math.jussieu.fr wrote:
>>>>> In Krita there were comparisions like this:
>>>>>          fabs(x-y) < DBL_EPSILON
>>>> note that Qt also provides ways to compare qreals via
>>>> qFuzzyCompare; it takes
>>>> two floating point numbers and Does The Right Thing(tm) with them.
>>>>  so if you
>>>> don't have eigen about to save your buttocks but Qt is nearby ... use
>>>> qFuzzyCompare.
>>>
>>> Indeed, qFuzzyCompare is exactly the same as ei_isApprox with default
>>> precision.
>>>
>>> While we're at it: qFuzzyCompare relies on qAbs which is slow:
>>>
>>> from qglobal.h:
>>>
>>> template <typename T>
>>> inline T qAbs(const T &t) { return t >= 0 ? t : -t; }
>>>
>>> What is missing here is template specializations for int/float/double
>>> avoiding the runtime branching. std::abs() provides that. Is there any
>>> chance that Qt accepts a patch adding qAbs specializations wrapping
>>> around std::abs()? Am I missing something?
>>>
>>
>> A patch that uses std:abs() will most likely not be accepted since Qt
>> cannot depend on stl (unless you want to ifdef stl support). However, if
>> you provide a patch that implements the specializations stand alone, it
>> has a higher probability of being accepted.
>>
>> Girish
>> _______________________________________________
>> koffice-devel mailing list
>> koffice-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/koffice-devel
>>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]