"...but people advice that 64bit are 20 - 30% slower than the 32bit ..."
Could these people offer any evidence to this? Cite any benchmarks? I
would like to see the evidence of this before believing it to be true.
--David
Mohan2005 wrote:
Hello:
we also wish to convert out 32bit dual cores to 64bit dual cores to run java
applications (multiple instances with large JVM memory)
but people advice that 64bit are 20 - 30% slower than the 32bit with smaller
JVM.
why? and if true how to overcome??
thanks
Peter Stavrinides wrote:
Some of arguments presented hold some truths, but look at the bigger
picture... the point is that 64bit is a superior architecture to 32 bit,
but it is still maturing... the reasons for this are both hardware and
software related... the way we write programs will have to change to
take advantage of the new architecture, and the current generation of
hardware will no doubt mature to realize the potential of 64bit
architecture.
32 bits processors can represent numbers up to 4,294,967,295 while a
64-bit machine can represent numbers up to 18,446,744,073,709,551,615.
For modern hardware to take advantage of the processing power of the 64
bit architecture a system must have a minimum 4GB Ram, but probably
needs significantly more and more importantly the CAPACITY to take full
advantage of it, allocating it to running processes, with less there is
potential for lag.
64bit machines have been around since the 60's but only now are software
and hardware vendors supporting it for the mainstream market. So is
64bit better than 32bit right now? the answer is yes, a 64-bit processor
has more technology, a better design with more transistors, thus faster
speeds are possible. This is currently where the true benefit of
switching to a 64-bit processor lays, it has nothing to do with the
memory address space, which is exactly that, just space for more complex
computations.
Peter
Alexey Solofnenko wrote:
No, each of two 4GB processes will have only a half of the objects
under the same load. And I heard that GC does not scale linear with
heap size. And this is without multi-threading performance
considerations. As usual, your mileage may vary and only tests can
tell for sure.
- Alexey.
Caldarale, Charles R wrote:
From: Alexey Solofnenko [mailto:[EMAIL PROTECTED] Subject: Re:
Tomcat with 8 GB memory
I was under impression that GC does not scale linearly. That means
one 8GB process will be slower than two 4GB processes.
Not true. The time of a full GC using modern algorithms depends mostly
on the number and type of live objects, not the amount of heap space.
The number and type of live (reachable) objects stays relatively
constant for most application once the ramp-up period is over.
Consequently, running a single JVM with the largest heap you can fit in
the process space is the most efficient from a GC point of view. (Of
course, there are plenty of other reasons not to put all your eggs in
one basket.)
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Peter Stavrinides
Albourne Partners (Cyprus) Ltd
Tel: +357 22 750652
If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy, retain
or redistribute it. Please visit http://www.albourne.com/email.html for
important additional terms relating to this e-mail.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
