It is very relevant that LLVM look into handeling HDL and other binary
and analogue operation modeling capbilities, as well as expand this
abstractly above in the other direction to include complex structure
optimization that is critical in realtime, dynamic and VM operations.
Without confirming the true characteristics of the lower structure
types and operating characteristics (especially physical
implementation) it is not possible to coherently optimize complex code
sequences, especially with wide varieties of influences on abstract
operation.
Obviously, all characteristics of physical system implmentation should
be included in the standard techniques.
More importantly, given most of that model data (result values) is
fairly finite and known variable data ranges for most target
implementations, one must propogate these analytics to higher models.
There is no difference between the physics simulation techniques used
to confirm the physical chips and the same modeling through operations
sequences all the way up to complex physical modeling.
Here, though, is an immediate need to be able to model and optimize
for entire computational systems regardless of scope.
GPU, fpga, solid asic, cpu and memory... various signaling techniques
between locally... interdependencies beyond local arrangements.
The need to handle "signals propogation" models, including the physics
of telecom and the hardware characteristics of intermediate devices,
mandates a coherent and comprehensive modeling technique through the
entire scope of influencing structures.
Specificly: you can NOT design optimal multi proc or diverse proc
implementations without knowing everything (composite model) about
everything involved.
Typically one designs systems based on the entire system.
Code optimization must accomodate this awareness as well as introduce
advanced modeling to more simple designs. (conventional code
modernization)
I will indicate as well that complex physical systems also effect
computational optimization. Heat at a data center or on fiber mutex
causes some deviance from ideal specs. It is hot on that wire. Your
computation will stall due to telecom latency that CAN ALWAYS BE
MODELED and accomodated. Sure, if the last packet from remote proc was
late, you can guess about the next, but if you are running at midday
summer and this happens daily, changing the scheduling order is
mandatory.
I will also indicate that the set of variable characteristics used in
process modeling is identical numerically to that used in higher level
physics simulation. Everything from atomic physics (fpga) through
automobile heat and mechanical force transfer (turbulance and
environmental conditions at repeater) (wire) are of the exact same
processing technique and data set (superset with only the processing
technique differing).
Thus:
Both in order to accurately simulate and optimize modern computational
models, and due to the fundamental similarities in computational
process, LLVM should expand to handle ALL lower dependencies (hdl/etc)
(which are an obvious need anyways) as well as applying the techniques
of process modeling to all other similar mechanisms.
You will note that 3rd party scientific processes could easily be
optimized intrinsicly when the scope of their numerical model is
known, which depends on such things as materials physics specs and fea
modeling of ... the exact same systems that are thus selected to run
the model on.
There are few modern abstract modeling languages and systems, and most
are restricted use and highly isolated.
Code depends on hardware, operations depend on physical reality.
Obviously there is a need to fabricate the most comprehensive system
model now (all data options handled), allow optimal techniques to be
introduced later, and generate a finite set of modeling techniques
that handle most of the required situations.
I look forward to your response and discussions of this topic.
-Wilfred L. Guerin
WilfredGuerin at gmail.com
aim/msn/yp/gt/sk/etc "WilfredGuerin" icq 105758521
.
