Re: [bitfolk] Renumbering: resolver not working? still point…

Top Page

Reply to this message
Author: Alex Smith
Date:  
Subject: Re: [bitfolk] Renumbering: resolver not working? still points to 212.x, instead of 85.y on >=1 machine
I think the memory consumption and performance differences between
32-bit and 64-bit are slightly overblown - the reality as far as my
experience shows is that you won't notice the difference.

In many situations, an OS compiled for 64-bit can be quicker than the
32-bit version, as it can make use of the extra (and larger) registers
and so on that the 64-bit CPUs have.

Personally I'm in favour of going 64-bit, there's quite a few programs
which are now developed as "64-bit first" applications, where 32-bit
is becoming a bit of a legacy issue, to be updated later.

A couple of examples:

MongoDB - database sizes are limited to 2GB
http://docs.mongodb.org/manual/faq/fundamentals/#what-are-the-32-bit-limita=
tions
The "go" programming language
https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/qxlxu5RZAl0

I've had some of the issues with go - it didn't bother me too much
since I was just experimenting, but these things will come up more
often.

Ewan

On Wed, Jun 6, 2012 at 11:55 AM, Mat Johns <mat@???> wrote:
>>- 64-bit is alleged to be a little slower and use more memory
>> =A0 per-process compared to 32-bit.
>
> +1. I would have presumed that a large chunk of BitFolk's customer
> base are hobbyist's, developers and small businesses who are at the
> lower end of the RAM range. Admittedly we shouldn't make it too hard
> for Andy to drum up new business (as with success potentially comes
> more free upgrades), but for other suppliers I have dealt with who
> support both, I have been very particular that I wanted 32bit for the
> reasons we are discussing.
>
>> Even if I had a 2G RAM server, I'd still wa