Concerning Time.TimeDiff

Ketil Z. Malde ketil@ii.uib.no
20 Jun 2003 10:09:33 +0200


Alastair Reid <alastair@reid-consulting-uk.ltd.uk> writes:

> On Thursday 19 June 2003 2:59 pm, Ketil Z. Malde wrote:

>> What about CPUs with only native 32bit support,

> All you need to implement arbitrary sized N-bit arithmetic is a CPU which=
=20
> provides 'add with carry', 'subtract with carry', etc.  All CPUs I have e=
very=20
> used provide these operations and I think it's a safe bet that all future=
=20
> CPUs will provide them.

I'm not saying it'll be impossible to implement, just that if you only
have shorter operands, any opertaion on 64-bit entities must be
implemented as a much larger number of operations (around 64 muls and
16 adds if you use byte operations=B9)

>> What about computers with a >64 bit native type?

> Processors which provide 2*N*8-bit arithmetic sometimes provide N*8-bit=20
> arithmetic too

...again, it would be *possible*, but not efficient.

On the other hand, Integers will be optimized to use whatever features
available on a specific platform; it could use a single byte for small
numbers in the first case, or it could use the full 128 bit operations
for large numbers.

I'm not saying it's a very relevant problem; and I'd be the first to
agree that most CPUs now and in the future provide 64- or at least
32-bit operations (and probably not 128-bit ones).

> I suspect Integer could be optimized (by recognizing that most uses of In=
teger=20
> are for values that fit in 31 bits) so that the difference is pretty mini=
mal.=20=20

GMP (which I thought was used to implement Integer) is supposed to be
pretty good.

> But this would have limited effect on a date like 19 June 2003 which is (=
very=20
> roughly) 2^69 picoseconds since the epoch.

Yes.  And, as I mentioned previously, I don't think any application
spends a significant amount of time computing times.  The focus should
be on what't practical and simple from an API point of view, rather
than efficiency.  IMHO.

-kzm

=B9 OK, so that's fairly naive, and can surely be implemented more
efficiently.  But who multiplies times, anyway? Or, for that matter,
runs Haskell on an 8-bit CPU? :-)
--=20
If I haven't seen further, it is by standing in the footprints of giants