-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck,
On 3/1/2011 5:42 PM, Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Subject: Re: [OT] IIS7/isapi/tomcat performance > >> Are you saying that a 32-bit JVM running on a 64-bit machine >> somehow utilizes the 64-bit bus? Malarkey. > > I wouldn't bet on that. Intel goes to great pains to insure all of > the buses are fully utilized. On a 64-bit machine, all of the data > paths from RAM up to the L1 operand cache will be able to move twice > the number of items per cycle when the items are only 32 bits wide. The question I have is how does the bus controller know that there are multiple 32-bit values coming down the line, and that it can send them simultaneously down the bus? There's more data to be sent over the bus than just pointers to other pieces of data. You have to move the instruction itself, etc. so there's lots of opportunities for other data to get in the way of this "DRR-style" data transfer across the bus. > Between the L1 cache and the superscalar execution core, there may be > less of a gain, but since the core contains three ALUs and separate > load and store sections to service them, memory operations are > combined wherever possible to get data in and out as fast as > possible. I buy this argument, but that would only affect the processing of, say, a 64-bit pointer within the core... not the speed of passing that pointer around the rest of the machine. As you say, probably less of a gain. I'd love to see some real documentation and/or testing on this type of stuff. I certainly am somewhat naïve when it comes to details this low, but my intuition tells me that the CPU and bus aren't magic :) - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1tfa4ACgkQ9CaO5/Lv0PBxlQCgjvY/NcigAvD/jXIWfckKUbju tUgAn2bfMa3iEuQeUe0j2ZqmgVxGn+dx =Vubd -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
