ES3.1 Proposal Working Draft
MFC at uk.ibm.com
Mon Feb 25 02:15:07 PST 2008
Maciej Stachowiak <mjs at apple.com> wrote on 21/02/2008 16:14:22:
> On Feb 21, 2008, at 2:46 AM, Mike Cowlishaw wrote:
> > Maciej wrote on Wed Feb 20 14:28:33 PST 2008:
> >> Besides compatibility issues, this would be a significant performance
> >> regression for math-heavy code. I would consider this a showstopper
> >> to implementing such a change.
> > I'm inclined to agree that it is (unfortunately) probably not a good
> > idea
> > to simply replace the default binary arithmetic with decimal128 --
> > even
> > though this would give better precision for math applications, as
> > well as
> > all the other benefits of decimal arithmetic.
> > But I don't buy the performance argument -- decimal math packages are
> > respectably fast nowadays. See, for example, the measurements at
> > http://www2.hursley.ibm.com/decimal/dnperf.html -- a decDouble add
> > is a couple of hundred cycles in software.
> That benchmark isn't very useful because it doesn't compare to
> hardware binary floating point, and also because they are
> microbenchmarks so it's hard to tell how much impact there would be on
> a real app. However, hundreds of cycles even for simple operations
> like add sounds to me like it would be hundreds of times slower than
> hardware floating point.
Pentium basic arithmetic operations take from 1 cycle (pipelined add,
rarely achieved in practice) up to 39 cycles (divide). The figures at the
URL above for decimal FP software are worst-cases (for example, for Add, a
full-length subtraction that requires pre-alignment and post-rounding). A
simple x=x+1 is much faster.
> > That's roughly the same speed on
> > current processors as the hardware binary floating-point available
> > when
> > ECMAScript was first written.
> That's not really a relevant comparison. When ECMAScript was first
> written, people weren't using it to write complex web apps. Nowadays
> it would be be unacceptable even for a high-end phone to deliver the
> ECMAScript performance as slow as consumer desktops from that era.
That's a fair comment (phones). However, the path length for rendering
(say) a web page is huge compared to the time spent in arithmetic. (I did
a search for 'math-heavy' examples of several programming languages 3
years ago and didn't find any ECMAScript examples.) But if arithmetic
performance really is an issue, one could provide an option or attribute
to request binary arithmetic, perhaps.
> > In today's (unpipelined) decimal FP hardware it is much faster than
> > those
> > software measurements, of course, and there's no reason why future
> > implementations should not be within 10%-15% of binary FP.
> I do all my browsing on a MacBook Pro and an iPhone. As far as I know,
> neither of these has any kind of decimal FP hardware, nor do I expect
> their successors to support it any time soon (though I don't have
> inside knowledge on this). These systems are towards the high end of
> what is available to consumers.
Intel are studying decimal FP hardware, but have not announced any plans.
Of course, PowerPC (as of POWER6) has a decimal FPU...
> >> I also agree with Mark's comment that arbitrary-precision integers
> >> and
> >> arbitrary-precision rationals seem like more generally useful types
> >> than decimal floating point, if any numeric types are to be added,
> >> but that seems like an issue more for ES4 than 3.1.
> > I really do not understand that comment. Almost every numerate human
> > being on the planet uses decimal arithmetic every day; very few need
> > or use arbitrary-precision integers or rationals of more than a few
> > (decimal)
> > digits. And almost every commercial website and server deals with
> > currency, prices, and measurements.
> I don't think currency calculations are the only interesting kind of
> math. So if we need to add a software-implemented more accurate math
> type, why not go all the way? At least that is my first impression.
Currency calculations are not very interesting at all :-). But (outside
HPC and specialized processors such as graphics cards) they are by far the
> This is not directly related to my main point, which is about
> performance and which I think still stands.
In summary: software floating point (binary or decimal) is between one and
two orders of magnitude slower than hardware for individual instructions.
If (say) 5% of the instructions in an application are floating-point
arithmetic (a high estimate for applications such as parsers and browsers,
I suspect), that means the application would be about twice as slow using
software FP arithmetic. That's not really a 'showstopper' (but might
justify a 'do it the old way' switch).
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
More information about the Es4-discuss