To over simplify it, each variable in a 64 bit OS consumes 8 bytes (or 8 bits times 8 bytes is 64 bits) of memory where a 32 bit OS stores each variable in 4 bytes (or 8 bits times 4 bytes is 32 bits), so your memory usage for a program potentially doubles.

Since addresses (aka pointers) are also stored in these same values, then a 32 bit OS can't access more than one contiguous block of 4 gigs of memory (2^32). That can be a drag to the efficiency of some graphics editing programs who can't load an entire > 4 gig image into memory at first without slicing it up.

Another concern with Linux and Unix is that time is represented as number of seconds past 1/1/1970 and 32 bits to store this time will run out sometime in 2032.

There are various hacks and tricks around all of this (except for maybe the unix time issue, although I could be wrong and there's still loads of time to upgrade to 64 bit before 2032 anyway)

i386 is 32-bit, x86_64 is 64-bit. 64-bit software uses more memory but runs faster (in most cases - ymmv).

_________________
/ Peter

You did a far much better job of simplifying it than I did!

I feel that I need to point out that, in the case of a Linode (a small one anyway), the "uses more memory" thing is far more important to you than the "runs faster" thing. In low memory environments (let's say under a gig), 64-bit uses an unreasonable percentage more.

Slicehost AFAIK has *only* 2 advantages over Linode right now: better Raid and backups (for a fee).

Otherwise Linode wins hands down in basicaly any other comparison you can think of: better host HW, better value for money, 32-bit systems, bw sharing etc.

That said, if Slicehost starts offering European slices (and I *do* think they will ... afteral they have access to Rackspace's infrastructure now), I will most likely switch to Slicehost ;(.

Does the supposedly better RAID actually offer improved performance though? Linode seems to handily beat Slicehost on this Unixbench run, even on the file copy/read sections. I'm genuinely curious here - is there a reason that this sort of test wouldn't show the advantage of Slicehost's disk setup?

What is this better raid? Last I heard linode was on RAID-1 (or possibly RAID-10) - RAID-5 would be slower than that, if anything...

Have you tried the newark datacenter? Latency to europe is not bad at all... about 76 ms to London.

I though Slicehost used Raid 10 while Linode Raid 1, but that's not the point, those were the *only 2* advantages I could think of. If you look at anything else Linode comes ahead as a far better choice than Slicehost.

btmorex: I am in newark and don't get me wrong it's not that bad, but 3-way handshake is a bitch :(.

Yes, the author does have an account with Linode, and has been quite happy with it so far:-) I initially chose SH on the recommendation of some friends, and while I wasn't unhappy with their offering (quite the contrary, they're good people), Linode's is simply better for the money.

programs under 64bit os usually consume more memory

I wrote up a Amazon EC2 vs Linode Vs Slicehost vs Mosso Comparison.

@davidw. 32-bit is more memory efficient.

http://www.xenscale.com/docs/vps-comparison-matrix

Mosso's primary platform is essentially shared hosting and isn't comparable. I think the Cloud Servers offering comes from the Slicehost acquisition.

Even though EC2's entry level costs more, it does has some wonderful features like EBS and is definitely useful in your comparison--but don't compare it to a Linode 360!

In a very limited way, I tested a beefy PHP/MySQL app on a EC2 small instance (with and without EBS) vs. a Linode 1080. The Linode was more responsive. Even though the EC2 instance has more RAM, it was slower, especially when memcached was used--definitely not the result I expected.

// Another concern with Linux and Unix is that time is represented as number of seconds past 1/1/1970 and 32 bits to store this time will run out sometime in 2032.

Not another Y2K !!!!!

Jeff

I'm not sure how serious you are, but that's correct. It's called Y2038 or Y2K38. (It's 2038, not 2032.)