Warnings (was: Subsurface libdivecomputer branch merged with upstream..)

[Robert Helling]

Hi,

> On 16. Dec 2017, at 20:29, Lubomir I. Ivanov <neolit123 at gmail.com> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20171217/c180b2b9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20171217/c180b2b9/attachment.sig>