On Feb 25, 2008, at 2:15 AM, Mike Cowlishaw wrote: > 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.
Then I will ignore the details of the chart and assume "lots slower" unless you have better data. >>> 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.) There can be many factors affecting page loading and web application performance. There are many cases where JavaScript execution time is a significant component. > But if arithmetic performance really is an issue, one could provide > an option or attribute > to request binary arithmetic, perhaps. No, shipping a huge performance regression with an opt-out switch is not an acceptable option. >>> 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... Apple completed the Intel switch some time ago, since then PowerPC has not really been relevant to the devices on which people browse the web. My point remains, decimal FP hardware is not relevant for any current performance evaluations and will not be for some time. >> 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). If you don't think imposing a 2x slowdown on web apps is a showstopper then clearly we have very different views on performance. (Note, using your high estimate of two orders of magnitude it would be a 6x slowdown if 5% of an application's time [not instructions] is spent in floating point arithmetic.) From my point of view, this would be a massive regression and conclusively rules out the idea of replacing binary floating point with decimal floating point in ECMAScript. Regards, Maciej _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
