You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Francis GALIEGUE <fg...@one2team.com> on 2011/11/30 20:49:14 UTC
[OT] Re: Maximum memory that can be assigned to Tomcat on windows platform
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.
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Re: Maximum memory that can be assigned to Tomcat on windows platform
Posted by Francis GALIEGUE <fg...@one2team.com>.
On Wed, Nov 30, 2011 at 22:38, André Warnier <aw...@ice-sa.com> wrote:
[...]
>
> 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 ?
>
No, this depends on the bus width, not the address space. And bus
widths nowadays are rather in the range of 256/512 bits.
> 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 ?
>
This depends on the alignment the JVM uses. If it aligns to 8 bytes,
then yes, any integer will take up 8 bytes, but so will any byte. In
general, the alignment is 4 bytes, except for long values of course.
With a 4 byte alignment, this means you can store two ints in a
register, and it's then only a matter of logical ands/shifting to
obtain the value you want. And these operations are ultra fast ;)
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] Re: Maximum memory that can be assigned to Tomcat on windows platform
Posted by Ilya Kazakevich <Il...@JetBrains.com>.
>>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 ?
That depends on front bus width. Modern PCs has 64-bit bus AFAIK.
In "64-bit CPU" 64 is register size and nothing else (although 86x64 mode
has some differences with IA32)
>>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).
Java integers are always 32bit, are not they?
C int may vary from 16 (in BCC 3.1 for DOS) to 64.
64-bit processor mode gives you ability to:
1) address more memory (2^64 bytes theoretically).
2) store more data in register so CPU could now operate 64bit numbers and
you need one operation to do something with two 64bit objects opposite to
two operations on 32bit.
3) v86 mode is disabled so you can't run 16bit apps :)
4) use new registers, new SSE instructions and so on:
http://en.wikipedia.org/wiki/X86-64#Architectural_features
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Re: Maximum memory that can be assigned to Tomcat on windows
platform
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org