[Development] Proposing reversal of the Math3D qreal->float change

Thu Sep 13 09:14:50 CEST 2012

On Sep 13, 2012, at 2:07 AM, ext Romain Pokrzywka <romain.pokrzywka at kdab.com> wrote:

> On Wednesday, September 12, 2012 07:10:52 AM lars.knoll at nokia.com wrote:
>> On Sep 12, 2012, at 12:27 AM, ext André Pönitz <andre.poenitz at mathematik.tu-
> chemnitz.de> wrote:
>>> On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote:
>>>> On 11/09/2012 13:34, Thiago Macieira wrote:
>>>>> I propose we revert it.
>>>> 
>>>> I propose we (I) fix the affected classes in QtMultimedia
>>>> and Qt3D. I'm away on business this week but I will make a
>>>> start asap.
>>> 
>>> I believe I mentioned that before. Anyway:
>>> 
>>> I think there are (medium term) only two acceptable solutions,
>>> none of them perfect:
>>> (a) keep everything as it is (or, rather, "was")
>>> (b) have fully functional real/double "verticals"
>> 
>> (c) Turn qreal into a double everywhere
>> 
>> This was rejected before by some, because it might make things slower on
>> ARM, but would have the advantage that it's fully source compatible with Qt
>> 4, solves the mess and would allow us to introduce floating point types
>> where required later.
>> 
>> Only minuses I can see are
>> (c1) the names of QXxxF classes which are double and not float based
>> (c2) possibly slower execution on ARM
>> (c3) Somewhat higher memory consumption on ARM
>> 
>> (c1) is not easily fixed. But (c2) seems to be less of an issue these days.
>> At least for the Cortex A9 ARM claims very good double precision support.
>> Older CPUs also have some support through VFPv2/3. (c3) should also become
>> less and less of an issue moving forward.
>> 
>> So to bring this up again: How about turning qreal into a typedef for double
>> on all platforms and remove the mess this way? Whereever we need (or want
>> to use) floats, let's use them explicitly.
> 
> I think the statements "might make things slower on ARM" and  "seems to be 
> less of an issue these days" are a little misleading and too optimistic.
> 
> From my own experience, using double on ARM has a serious impact on 
> performance at many levels: data size, code generation, and even FPU options.
> 
> Indeed, from what I've read it seems like the Cortex-A9 is significantly 
> closing the gap between float and double (although not eliminating it), but's 
> it's really the only platform that does. [1]

True, but more and more embedded systems will start using that platform. My main proposal is that the default (and supported) build of Qt on ARM uses doubles for qreal. If we keep the typedef, you could still typedef it to use float at your own risk :)
> 
> Every other platform, Cortex-A8 and previous ARM architectures, and even Intel 
> Atom, will suffer badly from switching from floats to doubles, even though 
> they have VFP.
> 
> This is mainly due to the crappy VFP abilities in those platforms, combined 
> with the Cortex-A8 allowing use of the NEON co-processor as the FPU, with 
> massive performance improvements over VFP, but only available for floats. [2]
> 
> And it gets even worse when using -mfloat-abi=softfp. [3]

Yes, but softfp doesn't make sense with Qt Quick 2 anyway.
> 
> Now, considering that most usage of Qt on embedded platforms is either through 
> QGraphicsView or Qt Quick (1 and 2), both of them relying heavily on floating 
> point calculations (coordinate systems, painting with AA...), this is 
> definitely a decision with a potentially serious impact on most embedded 
> platforms.

One solution here is to explicitly use floats internally in Qt wherever possible and where it's critical to performance.
> 
> One may still argue that Qt5 should be targeting the latest and future 
> platforms instead of legacy and current ones. Fair enough. But I think the 
> consequences should be stressed more. Some extensive benchmarking would be 
> nice too, before deciding on one solution against the other.

As said above: It's about the default build that the Qt Project tests and supports.

We can keep the option of forcing qreal to float at least for now or until we've proven that the performance impact is acceptable.

Cheers,
Lars

> 
> [1] http://www.360doc.com/content/12/0806/14/350555_228637047.shtml
> [2] 
> http://processors.wiki.ti.com/index.php/Cortex_A8#Neon_and_VFP_both_support_floating_point.2C_which_should_I_use.3F
> [3] http://wiki.debian.org/ArmHardFloatPort/VfpComparison
> 
> Regards,
> Romain
> -- 
> Romain Pokrzywka | romain at kdab.com | Senior Qt Software Engineer & Trainer
> 650-632-4409
> 303 Twin Dolphin Dr., Redwood City, CA-94065
> KDAB (USA) LLC, a KDAB Group company
> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - Qt Experts - Platform-independent software solutions
> 
>> 
>> Cheers,
>> Lars
>> 
>>> Version (a) means the current mess will go on. but it has the
>>> distict charme of (a.1) not breaking anyones existing code and
>>> (a.2) sticking to feature freeze rules.
>>> 
>>> Version (b) is somewhat closer to a proper solution, but fails
>>> (a.1) and (a.2). It has also the disadvantage of requiring real
>>> work, and therefore to tie up resources.
>>> 
>>> Even with my usual "let's break feature freeze if the feature is
>>> cool enough" hat on, I am tempted to lean towards (a). We are
>>> late in the game, and there are one or two rather essential
>>> things to be done for Qt 5. Having applications lock up regularly
>>> does not exactly sound like a strong sell to me. And while partial
>>> and/or extremly slow window updates might give that warm and cosy
>>> sense of being back in Qt 2.1 times to some, I have ths nagging
>>> feeling that not everyone out there will appreciate it.
>>> 
>>> So, please, make the things that were there work again, and do
>>> not open up new construction sites. And yes, that may mean
>>> postpone stuff to Qt 6 (or maybe convincing the Chief in a year
>>> or two that having a QT_NO_COMPATIBILITY would be a feasible
>>> approach)
>>> 
>>> Andre'
>>> _______________________________________________
>>> Development mailing list
>>> Development at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>> 
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development