ES3.1 Proposal Working Draft

Maciej Stachowiak mjs at apple.com
Thu Feb 21 08:14:22 PST 2008


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.

> 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.

> 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.

>> 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.

This is not directly related to my main point, which is about  
performance and which I think still stands.

Regards,
Maciej




More information about the Es4-discuss mailing list