64-bit?

64-bit?

Posted Apr 18, 2004 5:39 UTC (Sun) by evgeny (guest, #774)
In reply to: 64-bit? by RichardRudell
Parent article: The Grumpy Editor goes 64-bit

> Worse, because "int" is still 32-bit, we should really call this the
> "36-bit" machine, i.e., many applications will break because they count
> the "number of things" using an "int"; if the "thing" is 32-bytes, the
> "int" overflows at 2^36 bytes. That's only 16 GB which is too near current
> reality for my liking.

I didn't get it at all. Nor the 32->36 step neither (more importantly) the connection between sizeof(int) and addressable memory - unless you're talking about braindamaged apps casting pointers to ints of some kind.

> Also, 64-bit mode beats 32-bit mode on Opteron only for "small memory"
> applications. "Big memory" applications, i.e., why you want 64-bits in
> the first place, still lose by 5-20%. See, the problem is pointers being
> 64-bits reduces the effective size of the L1/L2 cache and cause increased
> traffic to DDR.

By "big memory" you probably assume not big enough to hit the 2/3/4GB (depending on kernel patch) native limit of x86. Anything above should clearly favor 64bit.

> Typical applications show a 1.6x increase in memory space (each struct
> being a mix of pointers (64-bit) and ints (32-bit). The extra 8 registers
> and the new ABI (pass arguments in registers, no frame pointer) help, but
> you just can't overcome a 60% increase in memory traffic when you really
> need to use all that memory.

Uh? A typical app spends half of its allocation in pointers?! There are such apps certainly, but they are 1) not memory-hungry AND 2) don't need a high CPU<->RAM bandwidth. Anything really memory-intensive should use a contigous memory areas (arrays or some custom mappings) in the first place, in which case the overhead is negligible. The only exception is probably memory debuggers (BTW, one thing I miss badly for x86_64 is valgrind).

---

(Log in to post comments)