6 Jun
2012
6 Jun
'12
10:55 a.m.
- 64-bit is alleged to be a little slower and use more
memory
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 want a
32-bit system.
+1. Unless you are in spitting distance of the 32bit limit, I would
prefer to stick to 32bit.
> >A future memory upgrade (not planned as to
when) will obviously push
> >more people into the space where>2G RAM per process would be
> >beneficial, so I will consider switching to only 64-bit by that
> >time. Will anyone be terribly upset to leave 32-bit behind?
Upset, a little; no where near jumping ship (as BitFolk has always
exceeded expectations) but would prefer to keep the 32bit option (if
possible). Is it not possible to boot a 32bit Dom1 kernel from a 64bit
Dom0? Or is the overhead of maintaining the two sets of bootstraps?
~Mat
6 Jun
6 Jun
11:06 a.m.
New subject: 64-bit support
Hi Mat,
On Wed, Jun 06, 2012 at 11:55:39AM +0100, Mat Johns wrote:
Is it not possible to boot a 32bit Dom1 kernel from a
64bit Dom0?
Or is the overhead of maintaining the two sets of bootstraps?
The dom0s are already 64-bit, I was just trying to avoid having to
double the number of combinations of install type (and explain to
people which one they want). But feelings seem quite strong both
ways.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
11:16 a.m.
New subject: 64-bit support
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…
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(a)cyberfish.org> wrote:
- 64-bit is
alleged to be a little slower and use more memory
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 want
a 32-bit system.
+1. Unless you are in spitting distance of the 32bit limit, I would
prefer to stick to 32bit.
> >A future memory upgrade (not planned as
to when) will obviously push
> >more people into the space where>2G RAM per process would be
> >beneficial, so I will consider switching to only 64-bit by that
> >time. Will anyone be terribly upset to leave 32-bit behind?
Upset, a little; no where near jumping ship (as BitFolk has always
exceeded expectations) but would prefer to keep the 32bit option (if
possible). Is it not possible to boot a 32bit Dom1 kernel from a 64bit
Dom0? Or is the overhead of maintaining the two sets of bootstraps?
~Mat
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users 
5:07 p.m.
New subject: 64-bit support
Well, if you are going to run a database that wants to hold everything in
memory, then, yes 64 bits (and far more RAM than most of us have).
For the rest, <
http://stackoverflow.com/questions/9297334/why-do-i-see-big-differences-in-…
matches what I see on VMs here: 64 bit systems use much more memory.
Ian, on a phone, so sorry for the quoting
On Jun 6, 2012 12:17 PM, "Ewan Leith" <ewan(a)nutmegdata.co.uk> wrote:
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…
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(a)cyberfish.org> wrote:
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
- 64-bit
is alleged to be a little slower and use more memory
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 want
a 32-bit system.
+1. Unless you are in spitting distance of the 32bit limit, I would
prefer to stick to 32bit.
> >A future memory upgrade (not planned as
to when) will obviously push
> >more people into the space where>2G RAM per process would be
> >beneficial, so I will consider switching to only 64-bit by that
> >time. Will anyone be terribly upset to leave 32-bit behind?
Upset, a little; no where near jumping ship (as BitFolk has always
exceeded expectations) but would prefer to keep the 32bit option (if
possible). Is it not possible to boot a 32bit Dom1 kernel from a 64bit
Dom0? Or is the overhead of maintaining the two sets of bootstraps?
~Mat
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
5:13 p.m.
New subject: 64-bit support
Hello,
On Wed, Jun 06, 2012 at 06:07:52PM +0100, Ian wrote:
For the rest, <
http://stackoverflow.com/questions/9297334/why-do-i-see-big-differences-in-…
matches what I see on VMs here: 64 bit systems use much more memory.
It seems like even if I find some good benchmarks to do, or find
some good benchmarks to point to, there are still going to be people
who will argue against whatever conclusion the benchmarks come to
(or just completely ignore me).
Arguing with people who want to give me money has never worked that
well, and I would have to assume that they know their own usage
better, so it looks like it will just be easier to support both.
Probably will just default to 64-bit on everything and hide the
32-bit option away somewhere.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
4341
days inactive
4341
days old
4 comments
4 participants
participants (4)
-
Andy Smith -
Ewan Leith -
Ian -
Mat Johns