[erlang-questions] 64-bit erlang

Tony Finch dot@REDACTED
Thu Nov 29 17:08:14 CET 2007

On Thu, 29 Nov 2007, Joe Armstrong wrote:
> But why the sudden hop from 32 to 64 bits? if 32 bits can address 4G
> then 40 bits could address 1TB.

I expect it's for backwards-compatibility. 32 bit words fit neatly into 64
bit words without wasted space and without alignment problems.

> I just don't get this - 32 bits can distinguish 4G different addresses,
> 64 bits can distinguish 16 exabytes given that a hardware designer will
> use some of the bits in a register and the rest for an address then a 22
> bit instruction and 42 bit pointer would allow access to 4 TB of data -
> in this case the "natural size" of a pointer and an integer should be 42
> bits.

Whenever instruction set designers have tried this in the past it has
turned out to have been a mistake that limited the lifetime of the
architecture or required work-arounds, e.g. IBM 360, Motorola 68000,
Acorn-era ARMs. The x86 has gone through four architecture overhauls to
extend its address space so it's probably the best example of all.

There are already supercomputers with multiple terabytes of RAM, so any
CPU that aspires to the high end needs more than 40 bits of address space
now, and will need to extend that in the future. For example, x86-64
currently has 48 bits of address space and reserves the remaining 16 bits
for expansion. Large address spaces will be useful for mmapping large data
sets even if they don't fit in RAM, so it's easy to see 40 or 50 bits
being necessary for lots of apps in the near future.

> Compiler writers should allow the size of an integer to be any
> reasonable value and not just a power of two - can somebody explain this
> "power of two fetish" to me so I can understand

If you are on a mainstream CPU then non-aligned accesses will require two
memory cycles, one for each word that is affected. x86 allows this but the
performance is poor; many other CPUs forbid it to avoid complexity.
Non-aligned accesses also have horrible cache coherency and concurrency

> Is it possible to change the emulator to work with 40 bit integers - you
> might have to be a bit devious. If P points to a struct that is 40 bits
> long (say a byte + a 32 bit integer) then *(P+1) would point to the next
> struct. Is this less efficient than a 64 bit program? - who knows -
> caching might make this more efficient.

If you lay them out in memory like this:

|----|----|----|----|----|----|----|----| 40 bit words
|-------|-------|-------|-------|-------| 64 bit words

Then half of your 40 bit words will require two memory accesses to
manipulate, either by the CPU in hardware, or by the emulator in software.
The latter increases your register pressure, which on x86-64 would
probably eliminate the advantage of having more registers.

Note also that the above diagram spans five 64 bit words, whereas a cache
line is eight or sixteen words. This means that the pattern of 40 bit
words will be different in each cache line and some 40 bit words will span
lines, hurting the cache.

> Are there no memory extenders that allow a 32 bit application to address
> memory outside the 4G address space?

The x86 Physical Address Extension allows an operating system to deal with
up to 64 GB RAM (36 bits), though each segment is still limited to 32 bit
offsets. Most operating systems do not allow userland programs to use more
than one segment so they remain limited to 32 bits of addressibility.

Applications that deal with large data sets usually do so via a database
that handles the necessary paging.

An interesting slightly tangential thought is how to lay out tagged data
words for a dynamically typed language in a cache-friendly way, without
stealing bits so that you can support unboxed floats (which makes sense
when they are the same size as pointers and ints). It might also make
sense to unbox short (0 to 8 byte) binaries. If you assume an eight word
cache line, you can comfortably fit seven data words, seven tag bytes, and
one byte of wastage thus:


f.a.n.finch  <dot@REDACTED>  http://dotat.at/

More information about the erlang-questions mailing list