Re: Concerns about AMD64 port

[Eric Sharkey <sharkey@netrics.com>]

> On Thu, Feb 05, 2004 at 11:43:20AM -0500, C. Scott Ananian wrote:
> > On Thu, 5 Feb 2004, Stephen Frost wrote:
> >=20
> > > In general it is, there are specific cases where 32bit apps are faster
> > > but there's corner cases for everything.
> >=20
> > 32-bit apps will almost always use less memory.  For whatever that's
> > worth.
> 
> I saw a quote long ago about the average increase in size for AMD64
> 64bit binaries was extremely small, iirc below 5-10%. So the increase
> in size of native binaries probably offsets the need to load all the
> supporting 32bit libraries for the one 32bit app you end up using.

You miss the point.  It's not code size that matters so much, but
data size, and it's very application dependent.

If you have a linked list of structures with small data elements,
the amount of memory can balloon up way more than 5-10%.

  struct node_t {
    int data;
    struct node_t *next;
    struct node_t *previous;
  }

sizeof(node_t) will double in this case.  (Not only will the size
of the pointers double, but due to data alignment needs, 32 bits of padding
get inserted between data and next.)  Any application written without care
to placement of elements within a structure (interleving pointers and
ints, for instance) can generate a lot of this type of padding.

That's a contrived example, but I think you get the point.

This also has an effect on cache utilization.  The number of pointers
that fit in your L1/L2 cache gets cut in half when the pointer size
doubles.

For some applications, this can be a big deal.

Eric