| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
P1788,IA, to be successful, will have to be a living implementation based on the Standard and capable or surviving changing technology and changing needs. If you required a specific hardware implementation, it would: 1) become slowly obsolete based on new architectures and processors; and 2) be extremely difficult to get the approval of the larger group of experts that will serve on the sponsor ballot, including, most likely, representatives of the various hardware, silicon, and software implementors as well as other academicians along with many members of this group.
I believe your goal should be create a standard for Interval Arithmetic that yields the SAME answer to computations with the SAME input and SAME operations across hardware implementations, and software languages. This should be a major goal where correctness is more important the speed. Try to think about the problems of multiple operations and the order of execution, ie precedence of operations that was sidestepped in 754 being language dependent.
Speed in an interesting concept for an implementation. During the 754 battles, we had many arguments about the checking for underflow after each operation would cost 1 extra clock cycles for a particular vendor and slow that vendors machine down to be to slow to be competitive. I am sure the same arguments will come up here again although you do not have a lot of existing implementations at risk.
One of the interesting facts that came out of the 754 arguments was the portion of the time that the processor actually spent on FP operations, or in your case IA operations, in performing a specific user function. In one very highly concocted example the processor was doing a floating point operation 45% of time and an extra cycle in each operation really hurt. Most of the applications had the actual use of the FP hardware being a very surprisingly small part of the machine cycle count in a normal environment where an extra cycle/operation or two to get the correct answer was not worth measuring.. It may be useful to look at the applications of IA, based on this developing standard, and drive the acceptance of IA that will then drive the folks to make it faster, and still get the SAME answer.
Bob Davis David Hough 754R work wrote:
What does it mean to require hardware support of intervals? All Turing machines support interval arithmetic; it's a "simple matter ofprogramming."Is a microcoded implementation count as hardware or software? What about an optional external coprocessor card for interval processing? I think that requiring hardware implementation really amounts to requiring some minimal level of performance so that interval methods are competitive with other methods for solving problems. However that's very hard to specify, since there are so many ways of measuring performance and "easy to measure" and "relevant to end user" are usually disjoint. That's why language standards groups generally refuse to touch this issue - it's not just an IEEE idiosyncrasy. Quality of implementation issues are up to the user to decide based on criteria relevant to the user. To see where this leads, one can look at the various SPEC results which aren't more than a very general sort of help to users because they correlate so poorly with delivered performance of ISV applications on which most computer performance procurement depends. Even so, the best way to get interval performance improved is probably to get 1788 finalized, then get language standards that support 1788, then get realistic open source applications written according to those language standardsthat can be used to compare performance on platforms, then get an organization like SPEC to select a few of those to measureinterval performance, then get end users interested enough to make procurementdecisions based on those results. If all goes really well this could all happen in ten years, but twenty might be a more realistic guess.
-- Respectfully, Bob Davis bob@xxxxxxxx 408-857-1273