7 ms·

> Current generation Atoms are 32-bit only Some lines of Atoms since mid-2010 or so have supported x86_64. The Sxxxx "server" atoms released at the end of 2012

> Current generation Atoms are 32-bit only Some lines of Atoms since mid-2010 or so have supported x86_64. The Sxxxx "server" atoms released at the end of 2012 are all 64-bit-enabled, for example, although they can still only take 8GB of RAM: http://ark.intel.com/products/series/71265 http://ark.intel.com/products/series/71265 I agree that this is mainly interesting if you're I/O-limited. Most benchmarks show a "regular" recent-gen Intel CPU performing around 5x-10x the Atom, so if you're CPU-limited, even a low-end VPS that gives you an average of 1/4 share of a core will probably outperform sole tenancy on an Atom core. But a high-contention VPS in most cases will give you much worse I/O performance. Also, the storage space and bandwidth quota here are much better than with a comparably priced VPS.

dragontamer 13y ago
Thanks for pointing that out. It seems odd to me that a system that only supports single-channel DDR2 RAM would be 64-bit however. With so little RAM, the benefits of 64-bit computing are basically void.
- justincormack 13y ago
  But it is more work to make a 32 bit system. They are probably all 64 bit locked into 32 bit compatibility mode.
- Tobu 13y ago
  Their 64bit kernels can run a 32bit distro too. With multiarch you also get to cherry-pick packages of the other arch.
- icebraining 13y ago
  The virtual space can be useful too. I remember reading that Go had some issues due to the limited address space in 32-bit systems.
  - _delirium 13y ago
    Yeah, that's an issue with conservative garbage collectors. When memory actually in use is a large fraction of the address space, then random values can look like pointers too often. When valid_memory << address_space, on the other hand, most non-pointer values won't alias a valid pointer. The specific issue with Go was significantly mitigated in Go 1.1 by making much more of the GC precise rather than conservative. Here's a comment from about a month ago on the current state: http://code.google.com/p/go/issues/detail?id=909#c59 http://code.google.com/p/go/issues/detail?id=909#c59
- csense 13y ago
  Isn't the x86_64 instruction set more RISC-like and compiler-friendly (i.e. more registers, 3-address instructions)?

dragontamer 13y ago

Thanks for pointing that out. It seems odd to me that a system that only supports single-channel DDR2 RAM would be 64-bit however. With so little RAM, the benefits of 64-bit computing are basically void.

justincormack 13y ago
But it is more work to make a 32 bit system. They are probably all 64 bit locked into 32 bit compatibility mode.
Tobu 13y ago
Their 64bit kernels can run a 32bit distro too. With multiarch you also get to cherry-pick packages of the other arch.
icebraining 13y ago
The virtual space can be useful too. I remember reading that Go had some issues due to the limited address space in 32-bit systems.
- _delirium 13y ago
  Yeah, that's an issue with conservative garbage collectors. When memory actually in use is a large fraction of the address space, then random values can look like pointers too often. When valid_memory << address_space, on the other hand, most non-pointer values won't alias a valid pointer. The specific issue with Go was significantly mitigated in Go 1.1 by making much more of the GC precise rather than conservative. Here's a comment from about a month ago on the current state: http://code.google.com/p/go/issues/detail?id=909#c59 http://code.google.com/p/go/issues/detail?id=909#c59
csense 13y ago
Isn't the x86_64 instruction set more RISC-like and compiler-friendly (i.e. more registers, 3-address instructions)?