Francis GALIEGUE wrote:
On Wed, Nov 30, 2011 at 18:51, Christopher Schultz
<ch...@christopherschultz.net> wrote:
[...]
Running a machine with more than 4GiB in 32-bit mode isn't stupid at
all IMO. If you have relatively small processes, there's no need for
the overhead of 64-bit even if you have 16GiB or more.
This is quite the opposite: a 32bit OS has _more_ overhead than a
64bit OS when running on a 64bit CPU.
Just consider filesystem calls such as read(), write(), seek(): their
arguments are 64bits, not 32, and have been so before 64bit was even
common (2+ GB files are common place today). With a 32bit OS on a
64bit CPU, you eat up two registers whereas a 64bit OS will take only
one.
And of course, this is without considering wasted TLB space or the
sheer time to address just one memory page.
I am not knowledgeable at all in such questions, and while you are at it let me ask a
question :
Does the fact of having a system with a 64-bit CPU (and OS) necessarily (or usually) imply
that data transfers between CPU and RAM happen also 64-bit in parallel ?
For example, let' suppose that I have an application which handles a very large table of
integers (the integers themselves being < 2exp31), and that periodically all elements of
this table have to be updated.
My understanding is that under a 32-bit platform, each integer will occupy 32 bit, while
on a 64-bit platform each will occupy 64 bit (the source program remaining the same).
If there is not a corresponding 64-bit parallel transfer between CPU and memory, then
using a 64-bit CPU would be detrimental, no ?
Or is this a non-sensical case nowadays ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
