Qt5 switching qreal from float to double on arm*

Sun Nov 3 17:57:13 UTC 2013

Note: adding back debian-arm at ..., please tell me if it's not necessary.

On Saturday 02 November 2013 23:25:57 peter green wrote:
> Lisandro Damián Nicanor Pérez Meyer wrote:
> > Any feedback will be kindly appreciated.
> 
> I've always thought there is something fundamentally wrong.
> 
> What is qreal supposed to be used for? If it's supposed to be used for
> things where float would be adequate then shouldn't it be float on all
> platforms? If it's supposed to be used for things where float is
> inadequate then why isn't it double on all platforms?
> 
> The current situation leads to people who develop on i386 and amd64
> (which is most developers) assuming that qreal is equivilent to double.
> Then we try and build it on arm* and float gets used. Sometimes this is
> ok because there was really no reason for the developer to be using
> double precision in the first place and there were no incorrect
> conversion assumptions. Sometimes this causes build failures which can
> be difficult to resolve* and I bet in some cases it causes more subtule
> bugs. It also goes against the principle of offering to the greatest
> extent possible the same functionality on all platforms.

Peter: I'm not in the position of changing qreal's existence, so I'm not here 
to argue if qreal is a good idea or not.

The important thing is that qreal has been in Qt since at least Qt3, and, as 
far as I remember, has always been defined to be double on archs that natively 
support it and float on those that didn't.

> Making qreal double on armhf but leaving it as float on armel will mean
> that canonical are no longer forced for fix bugs surrounding it. I'm
> sure canonical would like that but I also suspect it may cause severe
> degredation in the maintainance of QT software on those ports that stick
> with qreal.

I really don't understand where Canonical gets in here. I don't work for 
Canonical nor I am an Ubuntu maintainer .Qt5's change comes from Lars Knoll, 
the current main/lead architect of the project. And we are still left with the 
possibility to define what value will qreal take (see below).

I also don't understand what you mean with "ports that stick with qreal". 
qreal is a typedef which type is defined at compile time. Did you meant float?

> On the other hand presumablly there would be a performance hit from
> switching from float to double, especially on platforms which use
> software floating point (I presume that was why whoever controlled qt at
> the time made qreal float on arm in the first place).

That's why they added an option to bypass this at compile time (see my 
previous mail) and also the main reason that I left armel as float. Of course, 
it might be that some armhf's hardware isn't capable of doing double, which is 
not what I currently understand, but feel free to correct me.

But the most important thing here is that if the porters decide that we better 
stick to float for qreal, I have no problem in doing so.

> I found some older upstream discussion on what to do about float at
> https://groups.google.com/forum/#!topic/qt-project-list-development/dPcP3NAS
> Y1k
> 
> I also found some discussion at
> http://comments.gmane.org/gmane.comp.lib.qt.qt5-feedback/700 saying that
> on coretex A8 double was significantly slower than float.
> 
> Finally has there been any discussion with other linux distros. This is
> obviously something that impacts the ABI in a big way so ideally it's
> not something where we want different distros doing different things.

I have not participated in any way in upstream's decision nor I have the power 
to overcome them. Anyway, we are giving the choice of a compile-time parameter 
to better suit our needs on purpose.

Kinds regards, Lisandro.

-- 
18: Como se pueden evitar los problemas de alimentacion electrica
    * No coma cerca de un enchufe
    Damian Nadales
    http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20131103/9c589e2c/attachment.sig>