ES3.1 Proposal Working Draft

Mike Cowlishaw MFC at
Mon Feb 25 02:15:07 PST 2008


Maciej Stachowiak <mjs at> 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
> > -- 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 
most common.
> 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 mailing list