Browse thread
HLVM stuff
- David McClain
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2009-09-27 (17:33) |
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