So let me explain the original problem. This came up in the context of an ASPLOS talk today on deterministic execution in multithreaded systems. As an illustrative exercise, the speaker built a program that uses OpenMP parallelization primitives to compute the sum of the inverses of the first 1,000,000 integers using floating point computation. He observed that no two executions came up with the same answer (which, aside, means that he misconfigured OpenMP, but that's really a side issue), because no two executions combined the sub-results in the same order.
The underlying issue is that arithmetic on an integer ring is associative, commutative, and distributive in the usual way, while arithmetic on floating point is none of these. So this led me initially to two thoughts: 1. If, say, addition is handled using "+" in all cases, the optimizer will get this wrong (I was wrong about this, see below). 2. From a usability standpoint, the two operations *may* be different enough to justify using different operator names (e.g. "+" vs. "+."). My original objection to this in OCaml was that it was an overloading kludge. If it in fact constitutes an attempt to more accurately reflect a basic difference in underlying semantics, then that is another matter entirely. So what I was initially thinking was two sets of operators with distinct optimization rules, and then I was contemplating an accuracy of (human) expression issue. Subsequently I realized that the optimization issue is complete nonsense. The optimizer will not make decisions based on the fact that the method name was +. It will make decisions based on the fact that the concrete operator is int32-plus vs. float32-plus. So overloading "+" with operations involving different semantics doesn't confuse the optimizer at all. Okay. So now this brings us back to the question, which is: should the operators be distinguished? If so, then we would probably need distinct algorithm statements for the two families of matrix operations. On the other hand, it helps that we do not do any implicit casts, which means that these operations cannot be mixed in ill-advised ways. Given that the optimizer will not be confused after all, it may be sufficient to assert that people who use floating point arithmetic in gross ignorance have already given up any reasonable expectation of a comprehensible result. I really don't like breaking with tradition on this, but for the first time I see a credible story for why doing so might make sense. Opinions? shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
