Paul A. Clayton (paaronclayton.delete@this.gmail.com) on August 17, 2012 10:43 am wrote:

> 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.)

I think you have to distinguish between the static and dynamic occurrence
of carefully-tuned software: out of the millions of apps, the vast majority
are not very performance-sensitive, and won't be tweaked and tuned to any
great extent. However, a relatively small number of programs account for
a disproportionate fraction of total compute cycles - stuff like database
kernels, webservers, 3d game engines, video decode, Java VM - and many of those will
be much more carefully optimized than the "average" program.

IOW, if you spend 90% of your cpu cycles running just 10 cpu-intensive
programs, and 8 out of 10 of those are carefully tuned for 64bit, then
you may get a lot more benefit than the "just recompile" figure would suggest.

> Without special
> support in the ISA, pointer compression will
> cost some extra operations.

Yes, but I can say from experience that it works pretty well on modern
machines. Unless you're in tight code with everything in L1 cache, then
a modern superscalar OoO has plenty of spare ALU cycles
to do a few shift and mask operations, and the benefit of reducing cache
misses greatly outweighs the cost of those extra operations.

Also modern x86's do most misaligned accesses really fast, which helps in
dealing with the resulting packed data structures.

> 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.)

Yes. A template class with appropriate inlined implicit conversion operators
to get a full 64bit pointer when appropriate. It can be transparent to most
of the code.

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

Well, it's the usual tradeoff between the software effort, and the resulting benefit
in speed and memory footprint. I happened to work for a while on a product which
was on the bleeding edge of both - the compiler for Mentor Graphics fpga-based
emulation system (I'm elsewhere now). And I learnt my trade in the 1980s, with
machines with < 1MIPS and < 1MB, where *everything* had to be pretty carefully
optimized. In a world of 3GHz+ cpu's and 4GB+ DRAM, software effort tends to be a
more critical resource. Hence the rise of languages like Java and C#, which claim
to reduce software effort by 2x or more, at the cost of reducing performance by
some factor.