[MLton-user] more optimization questions

[Matthew Fluet]

>>> Also, is it possible that the integer calculations (for the index)
>>> might cause any problems ?  Like maybe they are boxed or converting
>>> back and forth to tagged and un-tagged or something similar.
>> 
>> Because you are using the C codegen and because you're using PowerPC,
>> which hasn't received anything like the amount of tuning we've done on
>> x86, you may see different results there than what you or others have
>> seen on x86.
>
> That may be, but as Mathew Fluet pointed out on c.l.f, there is not much to 
> optimize.  This is a finite difference code.  Loop, do fp, loop some more. 
> No transcendental functions or any complex logic, or even bit-twiddling.
>
> That's what makes this so confusing.  IME, optimizing compilers like mlton 
> and gambit-c for scheme do very, very well on simple loop/float constructs 
> like what I am doing.

I can't speak for gambit-c, but MLton hasn't put any special effort into 
loop or floating-point operations.  In fact, we know we're missing some 
possible loop optimizations.  Also, since the GC doesn't handle pointers 
to object interiors, array accesses are always computed addresses, rather 
than striding a pointer.  You might also lose somewhat because MLton 
won't/can't common-subexp eliminate array reads, since the array is a 
mutable object.  (Again, this is a place where more sophisticated analyses 
might admit such elimination.)

> As for power-pc optimization, I'm really interested in helping with that. 
> Although with the mac bonehead decision to go to intel I can't see that 
> anyone is going to be very motivated to optimize anyting for power pc.

Well, since a native code power-pc backend is unlikely, any improvement to 
the C-codegen would benefit other platforms as well.

> I'll code up some simple examples to see if I can understand the intermediate 
> files a little better.  Also smaller examples might help me narrow in on what 
> is going on.  There must be something going on - the difference is just too 
> big.

You're welcome to post code (to http://www.mlton.org/TemporaryUpload).