[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Clause 10, Expression Evaluation
On Aug 1, 2007, at 8:06 PM, Malcolm Cohen wrote:
Finally on this point, even if binary FP is faster than decimal
FP,
when decimal hardware is being used the difference might well be
tiny (viz disappear into the noise). Maybe, maybe not, but since
decimal hardware is not available much now, I don't think we can
reliably predict its future.
Machines which do have both, binary is much faster. Looking at the
circuits, one can see why. I doubt it's going to change, unless
people decide that decimal is what they really want, and we throw a
lot of tranistors and wires to it, and only do binary as an
afterthought.
But theoretical breakthroughs do occur, I suppose.
.....
Conclusion: "always faster and more accurate" is a bit misleading.
I think a better characterisation is that
"Binary FP has some speed (or cost) advantage - how big this
advantage
will be in the near future is hard to predict - and some
precision
advantage (better rounding of imprecise results)."
While you are, no doubt, correct in principle I think David is close
enough to right in practice for the foreseeable future that we're
splitting hairs on this point.
BTW, I also think that if decimal FP is more than 10% slower in the
eventual
hardware it will be very hard to get it accepted in a large part of
the
"high performance" community.
I don't think the high performance community will ever accept it,
unless government regulations forbade the construction of binary
hardware.
The primary decimal benefits accure to people who care more about how
their answers "look" than their speed (viz. spreadsheets, comparisons
to hand compuations, financial computations, etc.)
....(The next revision of Fortran
will have facilities for the program to specify decimal FP [or
indeed binary
FP] instead of the default, but no-one is going to use them until
hardware
is available or someone performs a software miracle.)
I would have thought that one could have gotten to decimal with a
KIND type now, admittedly outside the Standard model description ;>
I agree that very few Fortran users are likely to use it.
The large body of COBOL with it's longstanding usage suggests to me
that you are overly pessimistic about decimal's acceptance in the
wider community of people who compute things ;> It all depends on the
things being computed.
...Everyone running a program that takes nontrivial time turns on
optimisation at some level. Thus immediately entering the "non-
reproducible" world
(if they were not there already).
No doubt a switch or levels above and below the nondetermistic
"barrier" are plausible.
...
Well yes, but almost no-one does that. (Those who think they spot
hardware,
operating system, compiler or library bugs are usually wrong.)
Of course you realize that David is one of the folks who does
precisely that for a living, don't you? There is a class of person
whose job it is to code, to test, and to validate computer systems ;>
Unfortunately there are interactions between algorithm design and
decisions about parallelism and non-determinism so these steps
aren't as
orthogonal as one would like.
In fact I think they are backwards. You don't get a high-performance
program by throwing together a shell script with "eval" and then
spotting
you should be using a blocked cyclic distribution of seven matrices
over
your 200-cpu cluster. (That's exaggeration BTW, for the sake of
humour.)
No, but there are certainly folks who use tools like MATLAB or
Mathematica to prototype and then go off and hand craft code later.
Sometimes they may even employ automatic code generators for
intermediate levels of confidence building.
Languages like Fortress may blur the steps a little, providing some
high level looking original text, and then both compile time and
runtime optimizations (especially in the nondeterminsic modes ...
where you allow the dynamic optimization to change the code every
run, perhaps inside a run, so that the loop execution sequence
differs during the lifetime of long running programs). I would
certainly hope that turning *off* such features was an option for
debugging ... and for QA purposes (and no doubt some developers would
want to keep it inhibited in their production binaries ;>)
Performance is like security - you can't add it to a program, you
either
design it in in the first place or it's not there.
Good point, but like security there is no absolute. Well, not quite.
In security you can ensure secure execution. Put the box into a
sealed vault. Kill all lifeforms in the vault. Then let the system
run without any connection to the outside. It will be secure (not
very useful, but secure ;>). Perfect performance isn't possible ;>
OK, that's a significant exaggeration, and (especially with smaller
programs) one *can* "evolve" them towards higher performance - but
I think
it's generally true; in my experience evolving something towards
higher
performance usually requires throwing it away and designing a higher
performance version from scratch! (Others' experience might differ.)
Mine certainly does. Some bits do get replaced wholesale. Major bits
don't. Wholesale rewrites are seldom affordable for large enough
scale systems; their performance can be incrementally improved. No
doubt you could get massively better speedups if one started with a
clean sheet of paper. It's just seldom affordable.
--
Keith H. Bierman khbkhb@xxxxxxxxx | AIM kbiermank
5430 Nassau Circle East |
Cherry Hills Village, CO 80113 | 303-997-2749
<speaking for myself*> Copyright 2007