11:49 p.m.
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?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
2:45 a.m.
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
4:38 a.m.
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.
--
Florian Weimer / Red Hat Product Security Team
5:11 a.m.
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
12:15 p.m.
2013/8/2 Adam Jackson <ajax(a)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
3929
days inactive
3929
days old
4 comments
5 participants
participants (5)
-
Adam Jackson -
Florian Weimer -
Orion Poplawski -
Paulo César Pereira de Andrade -
Richard W.M. Jones