Within my memory, we switched from 8-bit to 16-bit to 32-bit and now to 64-bit computing.
We are now in a transitional period, when 64-bit CPUs exist and can process 32-bit code "natively" (by setting a bit in a CPU control register, without explicit affixes to each opcode or operand specification saying what the operands are 32-bits wide). Yet at the same time, in a 32-bit executable we can still do 64-bit math at the native speed of the 64-bit processor by using operand-size affixes.
In such an environment, expect 32-bit applications compiled into 64-bit executables to be slower, since C programmers (due to C's weakness as a systems programming language) tend to make "int32" typedefs that are processed more slowly in 32-bit mode due to affixes and possibly the need for sign-extension/truncation.
If you have a native 64-bit program (such as a cryptography program that makes extensive use of "int64" ("long long" in 32-bit gcc)) then it may show a speed improvement when a 64-bit executable.
Down the road, expect post-transition CPUs that can only process "int32"s with a slight speed hit.
Benchmarking 16-bit versus 32-bit on today's top end processors would be interesting, though it is important to distinguish between "16-bit applications" and "32-bit applications compiled in 16-bit mode".
Slashdot Mirror
Also note that snailSpam is alleged the primary source of revenue to the USPS. So there's an economic incentive to NOT treat it like eSpam.
Nah, these guys are just scam artists. Google ranks pages by what pages link to them; these people seem unaware of this, andf aren't testing for it.
We are now in a transitional period, when 64-bit CPUs exist and can process 32-bit code "natively" (by setting a bit in a CPU control register, without explicit affixes to each opcode or operand specification saying what the operands are 32-bits wide). Yet at the same time, in a 32-bit executable we can still do 64-bit math at the native speed of the 64-bit processor by using operand-size affixes.
In such an environment, expect 32-bit applications compiled into 64-bit executables to be slower, since C programmers (due to C's weakness as a systems programming language) tend to make "int32" typedefs that are processed more slowly in 32-bit mode due to affixes and possibly the need for sign-extension/truncation.
If you have a native 64-bit program (such as a cryptography program that makes extensive use of "int64" ("long long" in 32-bit gcc)) then it may show a speed improvement when a 64-bit executable.
Down the road, expect post-transition CPUs that can only process "int32"s with a slight speed hit.
Benchmarking 16-bit versus 32-bit on today's top end processors would be interesting, though it is important to distinguish between "16-bit applications" and "32-bit applications compiled in 16-bit mode".