John W. Colby
jwcolby at colbyconsulting.com
Wed May 18 13:35:43 CDT 2005
Hey, we're going to end up with VLIW processors with registers of 256 bits or even bigger. I vote we just stop development until those machines come out so we don't have to convert all our apps. <VBG> John W. Colby www.ColbyConsulting.com Contribute your unused CPU cycles to a good cause: http://folding.stanford.edu/ -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Scott Marcus Sent: Wednesday, May 18, 2005 2:07 PM To: Access Developers discussion and problem solving Subject: RE: Integers vs. Long Integers Was: RE: [AccessD] Global Variable LOL: This type of reasoning will make all of your code "bad practice" when your applications are run on a 64bit edition of Windows. Better convert now so that efficiency is there when it happens. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com Sent: Wednesday, May 18, 2005 1:17 PM To: accessd at databaseadvisors.com Subject: Integers vs. Long Integers Was: RE: [AccessD] Global Variable An integer is a 16 bit variable. Which means, on a 32 bit system (which includes almost anything running Windows), for the processor to use that 16 bit variable, it first converts it into a 32 bit variable. Then it does what it needs to do, then converts it back to a 16 bit variable. A long integer is a 32 bit variable. So it doesn't need to be converted. That means, for every 'transaction' between an integer and a long integer, the integer is going to take longer (3 steps instead of 1) Drew