Richard Cownie (tich.delete@this.pobox.com) on August 17, 2012 8:46 am wrote:
[snip]
> That seems plausible *if* you just take a big C or C++
> program and naively recompile it for 64bits with minimal
> changes to the source code. Because then suddenly all
> pointers change from 4byte with 4byte alignment, to 8byte
> with 8byte alignment (and in C++, any object with virtual
> methods gets an 8byte header with 8byte alignment, for the
> vtable pointer). If you haven't been careful, that makes
> many data structures 1.5x - 2x bigger, so then your cache
> miss rates go up, making it slower.

Getting software to be recompiled seems difficult enough. (I think it would be nice if C/C++ allowed the compiler to rearrange internal data structures for the sake of optimization--memory use or performance.)

> You can do better though, if you're prepared to tune your
> code carefully, e.g. storing only 40 bits for pointers, or
> shifting them 2-3 bit to squeeze into a 32bit field. If
> you optimize your critical data structures, the increase in
> data size can be kept to ~ 1.1x (rather than > 1.5x), and
> then the performance hit from the larger data structures is
> probably only 2% or so.

Without special support in the ISA, pointer compression will
cost some extra operations. (One could imagine an ISA that would perform partial loads for unaligned accesses--a bit like the early ARM processors except with sign or zero extension rather than rotation. This would make loading such pointers "free".) In addition, the programming language is not likely to support such easily. (With C++, one could presumably implement compressed pointers in much the same way one can implement smart pointers.)

> This all depends on what kind of app it is, of course - my
> experience is with a big EDA app, in C++, with 100s of
> different classes, most of which were at least 50% pointers,
> so keeping pointers small was a big deal.

A more likely scenario is combining fat pointers and compressed pointers, so one still has a 64-bit pointer but it includes some type (or other) metadata. (Some Java implementations do this. AArch64's optional ignoring of the 8 MSbits might be targeted to such uses.)

(I like pointer compression, but I am biased in favor of microoptimizations. Practicality seems to favor ordinary pointers in a flat memory space.)