http://doc.qt.digia.com/4.6/qtglobal.html#qreal-typedef
typedef qreal
Typedef for double on all platforms except for those using CPUs with ARM architectures. On ARM-based platforms, qreal is a typedef for float for performance reasons.
This still seems to be the case for 4.8 as well.
This lead to the following compile error on arm in kst:
/builddir/build/BUILD/kst-2.0.7/src/libkstapp/plotrenderitem.cpp:561:33: error: no matching function for call to 'qMin(double&, qreal)' y = qMin(y, plotItem()->yMax()); ^
If there is scientific type codes using qreal this might lead to some precision issues as well.
Is double really that much slower on arm?
On Thu, Aug 01, 2013 at 10:49:12PM -0600, Orion Poplawski wrote:
http://doc.qt.digia.com/4.6/qtglobal.html#qreal-typedef
typedef qreal
Typedef for double on all platforms except for those using CPUs with ARM architectures. On ARM-based platforms, qreal is a typedef for float for performance reasons.
[...]
Is double really that much slower on arm?
According to:
https://developer.android.com/training/articles/perf-tips.html#avoidfloat
there's no difference on modern hardware. (Note I didn't verify this.)
Judging by a google search for "qreal" "float" "arm" this difference causes endless problems. I even found a Fedora build bug related to it.
However it's a matter for upstream to fix it. Not something we could carry around only in Fedora IMHO.
Rich.
On 08/02/2013 09:45 AM, Richard W.M. Jones wrote:
https://developer.android.com/training/articles/perf-tips.html#avoidfloat
there's no difference on modern hardware. (Note I didn't verify this.)
That's about the Dalvik implementation. Other comments on that page suggest that it's so inefficient that a difference between float and double argument passing and computation overhead might be lost in that noise.
Hardware floating point operations except division should only take one cycle, for both single and double precision. If VFP requires passing double values in 32-bit register pairs, that might add some overhead, though.
Judging by a google search for "qreal" "float" "arm" this difference causes endless problems. I even found a Fedora build bug related to it.
However it's a matter for upstream to fix it. Not something we could carry around only in Fedora IMHO.
I would expect that consistency across Fedora architectures is more important than alignment to upstream.
On Fri, 2013-08-02 at 11:38 +0200, Florian Weimer wrote:
On 08/02/2013 09:45 AM, Richard W.M. Jones wrote:
Judging by a google search for "qreal" "float" "arm" this difference causes endless problems. I even found a Fedora build bug related to it.
However it's a matter for upstream to fix it. Not something we could carry around only in Fedora IMHO.
I would expect that consistency across Fedora architectures is more important than alignment to upstream.
If we're going to start casually disregarding binary portability between Fedora and other Linuxes, this is not where I'd start.
- ajax
2013/8/2 Adam Jackson ajax@redhat.com:
On Fri, 2013-08-02 at 11:38 +0200, Florian Weimer wrote:
On 08/02/2013 09:45 AM, Richard W.M. Jones wrote:
Judging by a google search for "qreal" "float" "arm" this difference causes endless problems. I even found a Fedora build bug related to it.
However it's a matter for upstream to fix it. Not something we could carry around only in Fedora IMHO.
I would expect that consistency across Fedora architectures is more important than alignment to upstream.
If we're going to start casually disregarding binary portability between Fedora and other Linuxes, this is not where I'd start.
Last time I looked at it, it was not easy either, because there was too much inline asm for 32 bit float, so, was not just switching some typedef. qreal as float also causes a lot of other problems because everybody expects qreal to be double, even when expanding those inline functions with a constant argument, need to cast it to float or it will not compile. Most trouble I had was python bindings, because there are too many dynamically generated files, and it is not trivial to patch those to create temporary vectors to convert float vectors to/from double vectors.
- ajax
Paulo
-
Adam Jackson -
Florian Weimer -
Orion Poplawski -
Paulo César Pereira de Andrade -
Richard W.M. Jones