ES3.1 Proposal Working Draft
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
>> implementing such a change.
> I'm inclined to agree that it is (unfortunately) probably not a good
> to simply replace the default binary arithmetic with decimal128 --
> 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
> 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
> 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
>> arbitrary-precision rationals seem like more generally useful types
>> than decimal floating point, if any numeric types are to be added,
>> 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
> use arbitrary-precision integers or rationals of more than a few
> 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.
More information about the Es4-discuss