Version française
Home     About     Download     Resources     Contact us    
Browse thread
HLVM stuff
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: David McClain <dbm@r...>
Subject: HLVM stuff
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