"...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:A.Solofnenko@(protected):
>>>>> 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@(protected)
>>>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>>>> For additional commands, e-mail: users-help@(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@(protected)
>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>> For additional commands, e-mail: users-help@(protected)
>>
>>
>>
>>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@(protected)
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)
