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

Romain Pokrzywka romain.pokrzywka at kdab.com
Thu Sep 13 02:07:52 CEST 2012


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]

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]

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 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.

[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



More information about the Development mailing list