Hmm.. I was thinking about the same few weeks ago. But I've read some posts from Akos F. and he explained, that just compilig with 3Dnow or sse2 may increase the speed by only 3%. If you want bigger increase you have to do some low-level programming in assembler. This is that "magic" that can give you 600% increase in speed. Of course 3Dnow and sse2 can be strong tools, but not by itself. They has to be used the right way.

		sub         esp, 0Ch 
		push        esi  
		push        edi
		mov         esi,dword ptr [esp+20h]
		mov         edi,dword ptr [esp+4Ch]
		// todo:fix: unaligned move, data potentialy allocated unaligned.
		// load two double floats from esi and edi
		movups xmm0, xmmword ptr [esi]
		shufps xmm0, xmm0, 050h
		movups xmm1, xmmword ptr [edi]
		shufps xmm1, xmm1, 050h
		// load remaining double float from esi and edi
		movups xmm2, xmmword ptr [esi]
		shufps xmm2, xmm2, 0FAh;
		movups xmm3, xmmword ptr [edi]
		shufps xmm3, xmm3, 0FAh;
		// vector subtraction
		subpd xmm0, xmm1
		subsd xmm2, xmm3

00604050  sub         esp,0Ch 
00604053  push        esi  
00604054  mov         esi,dword ptr [esp+1Ch] 
00604058  fld         dword ptr [esi] 
0060405A  push        edi  
0060405B  mov         edi,dword ptr [esp+4Ch] 
0060405F  fsub        dword ptr [edi] 
00604061  mov         eax,dword ptr [esp+88h] 
00604068  fstp        dword ptr [esp+0Ch] 
0060406C  fld         dword ptr [esi+4] 
0060406F  fsub        dword ptr [edi+4] 
00604072  fstp        dword ptr [esp+8] 
00604076  fld         dword ptr [esi+8] 
00604079  fsub        dword ptr [edi+8] 
0060407C  fstp        dword ptr [esp+10h]
00604080  fld         dword ptr [esp+8] 
00604084  fld         dword ptr [esp+0Ch] 
00604088  fld         dword ptr [esp+10h] 
....

00604050 83 EC 0C         sub         esp,0Ch 
00604053 56               push        esi  
00604054 57               push        edi  
00604055 8B 74 24 20      mov         esi,dword ptr [esp+20h] 
00604059 8B 7C 24 4C      mov         edi,dword ptr [esp+4Ch] 
0060405D 0F 10 06         movups      xmm0,xmmword ptr [esi] 
00604060 0F 10 0F         movups      xmm1,xmmword ptr [edi] 
00604063 0F 5C C1         subps       xmm0,xmm1 
00604066 0F C6 C1 4B      shufps      xmm0,xmm1,4Bh 
0060406A 8B 44 24 10      mov         eax,dword ptr [esp+10h] 
0060406E 0F 11 4C 24 04   movups      xmmword ptr [esp+4],xmm1 
00604073 89 44 24 10      mov         dword ptr [esp+10h],eax 
00604077 8B 84 24 88 00 00 00 mov         eax,dword ptr [esp+88h] 
0060407E 90               nop              
0060407F 90               nop              
00604080 D9 44 24 08      fld         dword ptr [esp+8] 
00604084 D9 44 24 0C      fld         dword ptr [esp+0Ch] 
00604088 D9 44 24 10      fld         dword ptr [esp+10h] 
...

Samples 	Address  	Code Bytes         	Instruction                 	Symbol 	CPU0 Event:0x41 	
        	0x494a50 	0x 56              	push esi                    	       	                	
        	0x494a51 	0x 57              	push edi                    	       	                	
        	0x494a52 	0x 8B 7C 24 0C     	mov edi,[esp+0ch]           	       	                	
        	0x494a56 	0x 8B F1           	mov esi,ecx                 	       	                	
        	0x494a58 	0x 3B F7           	cmp esi,edi                 	       	                	
        	0x494a5a 	0x 74 2D           	jz $+2fh (0x494a89)         	       	                	
        	0x494a5c 	0x 57              	push edi                    	       	                	
        	0x494a5d 	0x E8 7E F4 FF FF  	call $-00000b7dh (0x493ee0) 	       	                	
        	0x494a62 	0x 84 C0           	test al,al                  	       	                	
        	0x494a64 	0x 75 08           	jnz $+0ah (0x494a6e)        	       	                	
        	0x494a66 	0x 57              	push edi                    	       	                	
        	0x494a67 	0x 8B CE           	mov ecx,esi                 	       	                	
        	0x494a69 	0x E8 92 FE FF FF  	call $-00000169h (0x494900) 	       	                	
        	0x494a6e 	0x 33 C0           	xor eax,eax                 	       	                	
        	0x494a70 	0x 39 46 0C        	cmp [esi+0ch],eax           	       	                	
        	0x494a73 	0x 76 14           	jbe $+16h (0x494a89)       
[b] 	       	                	
23      	0x494a75 	0x 8B 4F 08        	mov ecx,[edi+08h]           	       	23              	
34      	0x494a78 	0x D9 04 81        	fld dword ptr [ecx+eax*4]   	       	34              	
988     	0x494a7b 	0x 8B 56 08        	mov edx,[esi+08h]           	       	988             	
        	0x494a7e 	0x D9 1C 82        	fstp dword ptr [edx+eax*4]  	       	                	
995     	0x494a81 	0x 83 C0 01        	add eax,01h                 	       	995             	
1       	0x494a84 	0x 3B 46 0C        	cmp eax,[esi+0ch]           	       	1               	
        	0x494a87 	0x 72 EC           	jb $-12h (0x494a75)
[/b]         	       	                	
        	0x494a89 	0x 5F              	pop edi                     	       	                	
        	0x494a8a 	0x 8B C6           	mov eax,esi                 	       	                	
        	0x494a8c 	0x 5E              	pop esi                     	       	                	
6       	0x494a8d 	0x C2 04 00        	ret 0004h                   	       	6  

cmp eax, [esi+0ch]
0x494a84 *((unsigned long*)(esi + 0xC)) = 0x11D

Other applications may well loose the same amount, because they are cache-dependant, and bigger pointers are using more cache-space. Yes, you could convince the compiler to use 32-bit pointers, but you'd have to also use a special C-library designed for this purpose [of which there are none available today AFAIK], and make sure that any calls to the OS itself is "filtered" suitably for your app, etc, etc. Which makes this variation fairly unpractical - it's unlikely that such a cache-bound app would gain noticably from running with more/bigger registers anyays, so those apps are better off running 32-bit binaries - unless you actually want bigger memory space, in which case 32-bit pointers are a moot point.

64-bit Data Models
Prior to the introduction of 64-bit platforms, it was generally believed that the introduction of 64-bit UNIX operating systems would naturally use the ILP64 data model. However, this view was too simplistic and overlooked optimizations that could be obtained by choosing a different data model.
Unfortunately, the C programming language does not provide a mechanism for adding new fundamental data types. Thus, providing 64-bit addressing and integer arithmetic capabilities involves changing the bindings or mappings of the existing data types or adding new data types to the language.
ISO/IEC 9899:1990, Programming Languages - C (ISO C) left the definition of the short int, the int, the long int, and the pointer deliberately vague to avoid artificially constraining hardware architectures that might benefit from defining these data types independent from the other. The only constraints were that ints must be no smaller than shorts, and longs must be no smaller than ints, and size_t must represent the largest unsigned type supported by an implementation. It is possible, for instance, to define a short as 16 bits, an int as 32 bits, a long as 64 bits and a pointer as 128 bits. The relationship between the fundamental data types can be expressed as:
sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) = sizeof(size_t)
Ignoring non-standard types, all three of the following 64-bit pointer data models satisfy the above relationship:
LP64 (also known as 4/8/8)
ILP64 (also known as 8/8/8)
LLP64 (also known as 4/4/8).
The differences between the three models lies in the non-pointer data types. The table below details the data types for the above three data models and includes LP32 and ILP32 for comparison purposes.

I may not have expressed it very clearly, but I _HAVE_ quite a bit of experience doing comparative benchmarking and improving performance on x86(-64) architecture, and I _DO_ know a fair bit about tricks you can play with passing multiple arguments in a single register, etc, etc.

I think you either misread or misunderstood my statement. I'm saying that in general, there is no direct correlation between the bitness of an application and/or of a CPU and the performance seen. I don't understand how that can be considered to be an "inflexible rule".

int main(void)
{
    return (char)1 + (char)1;
}

mov eax, 1
add eax, 1
ret

int main(int a, int b, int c, int d, int e, int f, int g, int h, int i, int k)
{
    return a + b + c + d + e + f + g + h + i + k;
}

add eax, ebx // a=a+b
add eax, ecx // a=a+c
add eax, edx // a=a+d
add eax, r08 // a=a+e
add eax, r09 // a=a+f
add eax, r10 // a=a+g
add eax, r11 // a=a+h
add eax, r12 // a=a+i
add eax, r13 // a=a+k
ret

I'm saying that in general, there is no direct correlation between the bitness of an application and/or of a CPU and the performance seen.

The point being that while it is possible to hand optimize a client and possibly improve the performance of that client - the effort in maintaining that client may not be justified by the performance gain. In which case, Rosetta would be better off putting 32 bit clients in the 64 bit client directories.

Prove that there's more than a 10% performance increase in moving to a 64 bit client and get Rosetta to produce a 64 bit client from the current code, and I'll start dual booting again.

Regardless of which was faster - my coding was a waste of effort for that project. Good for education, but a waste of effort, especially as I never used that screensaver again. :)

It wasn't optimized for 64 bit.. it was merely compiled in 64 bit. But we don't have optimized Rosetta clients yet, either.

Back at DF (Distributed Folding) they released a 64 bit client for a 64 bit flavor of a SUN OS. DF ran at a fairly consistent speed - i.e. 24 hours of crunching would produce roughly the same amount of results on Wednesday as they did on Tuesday. Stats whores tried out the 64 bit client, noticed a dramatic decline in results per day - so gave up and moved back to the 32 bit client.

It wasn't optimized for 64 bit.. it was merely compiled in 64 bit. But we don't have optimized Rosetta clients yet, either.

So from what I gather from reading that and what I already know, it seems right to assume there is no real benefit from making a 64-bit binary for Rosetta given what the program does as SSE/2 can fully accomodate that in 32-bit mode as it is. Right? :)

You've already stated that there is no speed benefit from using 64 bit pointers in such cases and the pointers would have to be hard coded to 32 bit.

Where is the benefit of hand optimization to 64 bit - that the developers had neither experience or time for - going to have come from? The point is not that all 64 bit apps are slower than 32 bit apps - but that 64 bits DOES NOT speed up every application as the 64 bit fanboys keep claiming.

And if I was using this as a penile enhancement motivation as you seem to imply - then I could probably move a couple of my systems from another project to enhance my score here.

Let's can the conspiracy theories - and move back to the frightening world of reality, shall we?

Get ahold of the older Rosetta code that's been mentioned; get ahold of the 64 bit version of the compiler that the Rosetta team is using; hand optimize it for 64 bit mode, and then run each client for 24 hours 3 times on the same WU. We'll see the variability of the same client on the same hardware running the same WU - and be able to see if there's a dramatic improvement between the 64 bit version and the 32 bit version.

Back at DF (Distributed Folding) they released a 64 bit client for a 64 bit flavor of a SUN OS. DF ran at a fairly consistent speed - i.e. 24 hours of crunching would produce roughly the same amount of results on Wednesday as they did on Tuesday. Stats whores tried out the 64 bit client, noticed a dramatic decline in results per day - so gave up and moved back to the 32 bit client.

It wasn't optimized for 64 bit.. it was merely compiled in 64 bit. But we don't have optimized Rosetta clients yet, either.

From a general standpoint, the "bitness" of the application does not equate to performance improvement or degredation. The thing that really matters is the source code, compiler/assembler, and linker taking advantage of the architecture. In some cases, 64-bit will not be faster or slower, but could take up almost twice the memory footprint. Only the developers, who have access to the source code and higher-level algorithms and know how to work with the architecture can tell if an application will see significant improvements.

However, bigger registers can also be a drawback - particularly for pointers. A pointer is now 8 bytes (64-bit) instead of 4 bytes (32-bit), so the cache can hold only half as many pointers. So for pointer-intensive code (such as binary trees or linked lists) where lots of pointers are being read/written, the cache becomes fulll much sooner.

I would suspect that the biggest gain for Rosetta would be to compile it to use SSE instructions, rather than to make it 64-bit. This is because it's a primarly floating point-intensive application, and it uses 32-bit single precision floats, so SSE would make sense.

ote also that very few compilers generate decent code for SSE in actual super-scalar mode. There's been a vectorization project for GCC, but it's still not ready for prime-time use. So it would probably require a bit of hand-coding to get anywhere close to ideal performance.

One of the things I would like to be able to do is designate a single machine as the "host" whereby all internet traffic goes through that one machine (uploading/downloading WU's etc..)