[MLton] latest benchmarks

[skaller]

On Wed, 2007-06-20 at 11:15 -0500, Matthew Fluet wrote:

> I suspect that the later behavior is due to the fact that on x86_64, 
> sequences (arrays/vectors) are indexed by 64-bit integers in the 
> primitive operations (sub, update, etc), but indexed by 32-bit integers 
> in the user code (Array.sub, Array.update, etc. since Int.int 
> corresponds to Int32.int).  Hence, there are quite a few 64/32 
> conversions going on.

I doubt that is quite correct. 32 to 64 bit 'in register' extension
is going to be invisibly fast.

The real problem is likely to be the opposite! A 32 bit memory
read is more expensive than a 64 bit read because the processor
actually reads 64 bits .. not a big deal. But for a 32 bit
write is is a big deal: the processor has to read 64 bits,
modify 32 of them, and store the resulting 64 bits back.

For this to work properly it has to be made atomic, which effectively
destroys cache write buffer transparency. 

Something like that anyhow .. :) the point is, the address and data
bus on an amd64 are 64 bits so random 32 bit operations actually 
cost MORE. 32 bits might be faster for sequential operations.

> * I note that with both native codegens and C codegens, with both 
> 20051205 and trunk, that -align 8 often has a positive impact on 
> runtime, and rarely has a significant negative impact.  This might be 
> due to the Opteron memory system.  Aligned reads probably help most on 
> Real64 intensive benchmarks.

See above.

> * The amd64 codegen is doing alright as compared to the x86 codegen.  I 
> see at most a factor of 2 slowdown, and a few speedups.  Again, I'm not 
> sure what real conclusions can be drawn. 

The conclusion is that your starting implementation is quite 
good enough to start with, but some more work may yield significant
performance gains. I say good work! And thanks! 

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net