Hi, > On 16. Dec 2017, at 20:29, Lubomir I. Ivanov <[email protected]> wrote: > > so yes, "float" is like a non-default sized type e.g. "short", yet > one's variable might fit in a "short" and it's perfectly fine to use > the non-default type. > while nowadays we don't have much of a size restrain using the smaller > type, it could be a good indication that we don't actually need the > whole 64bit precision for this variable. > the same way one could use a "char" vs an "int". > > on the other hand, if this causes more trouble than benefits, it's > probably best to just convert all the calculations to be with > "doubles", have consistency and silence the -Wall warnings.
from my very limited understanding: RAM is indeed big enough, so there is no
size constraint coming from there. But what is actually finite is CPU cache
size. So when the doubling in memory footprint makes the difference for some
calculation to fit in the cache vs the CPU has to fetch the data from RAM
several times the performance will hugely differ. Of course I have no idea at
all if this is any concern of us (not having done any significant performance
tuning ever). Plus there are these vector instructions where the CPU can do a
number of floating point instructions on different data in parallel: There the
number of things done at once is twice for float than for double (since twice
as many floats fit in the CPU). Again no idea at all if the compiler generates
this parallelism for us at any critical point.
Totally clueless:
Robert
PS: I remember we had a similar thing a while ago about signed vs unsigned it.
There I ended up making pretty much everything signed since unsigned produced
subtle bugs (since for example
unsigned int u = 1;
int s = -1;
if (u < s)
printf(„WTF\n“);
prints WTF as the comparison is done in unsigned. This caused problems around
dive time computations (where we had assumed dive durations would be unsigned).
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
