thanks for the clarifications. Peter Stavrinides wrote: > > This is really not true, (unless the machine in question is more than > four years then performance is faster for some operations and slower for > others), with a new machine you will gain. > > 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] >>> >>> >>> >>> >> >> > > -- > 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] > > >
-- View this message in context: http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11917676 Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
