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

[Romain Pokrzywka]

On Thursday, September 13, 2012 07:14:50 AM lars.knoll at nokia.com wrote:
> 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 :)

True, that would be a good enough solution, e.g. as an option to configure

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

Yep, I'm happy with that :)

Thx,
Romain

> 
> 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_suppor
> > t_floating_point.2C_which_should_I_use.3F [3]
> > http://wiki.debian.org/ArmHardFloatPort/VfpComparison
> > 
> > Regards,
> > Romain
> > 
> >> 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