Re: (long) 'severe' problems, was Re: Decorated intervals ARE intervals...
Dan Zuras wrote:
The 3rd choice is to count on optimizing compilers to know
when decoration results are not needed.
This generally is a good idea. I know compiler writers are clever and
fastidious people; and I would encourge them thinking in this direction.
However, it is not always enough.
One of the "bread and butter" aspects of interval computing is
branch-and-bound. As noted, decorated intervals are useless to these
algorithms; and knowing when to "switch" from bare intervals to bare
decorations is a run-time decision.
The 4th alternative is something that lives at level 1
which we have not thought much about at the lower levels.
You see, just because we associate a decoration with each
interval doesn't mean we have to STORE THEM IN THE SAME
PLACE.
Another approach a good compiler might use could be to
place all interval parts in one place (say offset from
a 128-bit aligned memory location called $INTERVALPART),
& put all decorations in ANOTHER place (say offset from
the memory location $DECORATION).
Thus the i'th interval object may be referenced by finding
its interval part at $INTERVALPART + i<<4 & its decoration
at $DECORATION + i (or + i<<1, as in the case described by
Ralph).
Memory is 100% packed up. The busses are 100% used to
transfer data rather than fluff. And the bandwidth for
computation is the best that money can buy.
I think in the rare cases when decorated intervals are explicitly desired
(or possibly required), that this may prove to be a very reasonable way for
compiler engineers to think about it.
Nate