Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4D6EFC56.6030902@christopherschultz.net>
Date: Wed, 02 Mar 2011 21:26:30 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: [OT] IIS7/isapi/tomcat performance
References: 
 <FF19241543251E479EB4BC7950552EA601D0F191@bocamail01.corp.nlg1.com>
 <99C8B2929B39C24493377AC7A121E21FACC54D4C54@USEA-EXCH8.na.uis.unisys.com>
 <632820.79256.qm@web113619.mail.gq1.yahoo.com>
 <FF19241543251E479EB4BC7950552EA601D0F1EF@bocamail01.corp.nlg1.com>
 <874355.34839.qm@web113610.mail.gq1.yahoo.com>
 <39553.49526.qm@web113612.mail.gq1.yahoo.com>
 <4D6D10C7.6020207@christopherschultz.net>
 <35327.83414.qm@web113603.mail.gq1.yahoo.com>
 <228787.69626.qm@web113618.mail.gq1.yahoo.com>
 <4D6D5EBC.9030504@christopherschultz.net>
 <99C8B2929B39C24493377AC7A121E21FACC55B337D@USEA-EXCH8.na.uis.unisys.com>
In-Reply-To: 
 <99C8B2929B39C24493377AC7A121E21FACC55B337D@USEA-EXCH8.na.uis.unisys.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

On 3/1/2011 6:09 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@christopherschultz.net] 
>> Subject: Re: [OT] IIS7/isapi/tomcat performance
> 
>> I don't understand why communicating a 64-bit value over a 
>> 64-bit bus would take longer than communicating a 32-bit 
>> value over a 64-bit bus:
> 
> Because you get *two* 32-bit values for one transfer, not just one. 

If, as you say, Intel can move 64 /bytes/ across a data path (if you
prefer that phrase over "the bus") then the word size really does make a
difference, here. They should be getting 16 32-bit words across such a
data path or 8 64-bit words.

If the pointers are doubling in size, this makes 64-bit mode go slower
because you get half the throughput when using word-sized values. Since
pointers in general are word-sized, they always suffer while other
(usually smaller) data does not.

The key is that the data path(s) are actually much wider than the word
size, which I didn't realize.

>> I also get that some processors (like Itanium) have an x84
>> processor core on the die
> 
> (Presumably, you meant x86.)  Sorry, Itanium was notoriously bad at running 32-bit apps.

I did mean x86. Lots of typing yesterday. The new Itaniums are supposed
to be actually worth it, though.

>> getting the data from point A to point B shouldn't matter
> 
> Sure it does, if you can batch multiple operand accesses together (which current Intel cores do).
> 
>> I suppose of the CPU knew it was in a 32-bit mode, it could 
>> adjust the number of clock ticks it had to wait around for 
>> 32-bit data to go through an adder, but that seems overly 
>> complicated for a straightforward CPU task.
> 
> Simple adders have only used one cycle for decades, regardless of the width.

If the clock tick is long enough :)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1u/FUACgkQ9CaO5/Lv0PBBHACfQsXMTwCmZywZrihKJI3M0k5c
BdoAn3VrrewxdTHZU0TZvR1pbQcKFwVj
=1Png
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org