HLVM stuff

HLVM stuff

[David McClain]

Okay, I think I may be seeing what you are driving at...

In order for any language to statically accommodate polymorphism, some  
uniform (boxed) representation of possible operands is needed.  
Whereas, with JIT, you have the option of detecting unboxed types at  
runtime and dispatching to code specifically tailored to that kind of  
operand. No boxing needed?

But now, in scientific computing, I would expect to see very little of  
the profile being occupied by these kinds of specializations, and much  
much more involved with whole array copying, and the mapping of  
operations over already unboxed array elements. If once could sense  
from function liveness analysis that some source array of floats, say,  
will no longer be needed, then its memory could be used for the result  
array of some operation, rather than constructing a whole new result  
array.

Wouldn't that kind of optimization pay off much more handsomely than  
dealing with these more symbolic oriented computations?

Dr. David McClain
dbm@refined-audiometrics.com

HLVM stuff

[David McClain]

... as a specific example, I remember dealing with stacks of images  
taken from an infrared imaging sensor -- perhaps 256 images, each of  
which is, say 512 x 512 pixels. I needed to obtain median pixel values  
from the stack and produce one "median image", as well as perform  
thresholding, masking, perhaps some dilation and erosion. And, also  
get the image 2-D FFT image.

So there we are dealing with an aggregate of 2^26 8-bit pixel values.  
Surely, the majority of time is spent processing pixels, and not  
dispatching over some polymorphic type...

Dr. David McClain
dbm@refined-audiometrics.com