[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] new cache

From: Dave Denholm
Subject: Re: [gnugo-devel] new cache
Date: 24 Jul 2003 21:00:14 +0100

Paul Pogonyshev <address@hidden> writes:

> Wolfgang Manner wrote:
> > i dont know how your linux box treats longlong. it still may be faster
> > to compare by yourself word 1 and if it disagrees: break
> > instead of comparing two longlong words
> > wolfgang
> i'm not sure about other architectures than x86, but the latter simply
> cannot compare two 64-bit values in one operation.  in other word, on
> x86 `long long' is an abstraction - it is supported by compiler (gcc),
> not processor itself.  i'd guess that this is true for all 32-bit
> processors.
> so it doesn't matter much what we use: `long long' or two `int's.  in
> terms of machine code on x86 (all 32-bit architectures).  but i would
> suggest two `int's simply because it's absolutely portable.

Without having followed the discussion (so not knowing if you are talking
about time critical code), I'd say why not use long long
since there are already 64-bit processors around (sparc, alpha) and
intel can't be that far from going mainstream. If it makes no difference
on 32-bit architectures, why not choose the one that is better on
64-bit architectures.

I would have thought that gcc should be able to generate psuedo-64-bit
operations at least as efficiently as they can be hand-coded out of
two ints.

(rather than doing a branch after one comparison, it might be
 more efficient to OR together the two comparisons... best just
 to trust the compiler to do its job...)

BTW if you want a 64-bit integer, I'd recommend type-defing something
rather than assuming long long is 64 bit.

I think the pattern matcher once had a typedef for a 32-bit integer,
and did a compile-time assertion that it was exactly 32 bits.

Dave Denholm              <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]