Hi, Maciej Stachowiak <[EMAIL PROTECTED]> 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 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). Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
