Re: ES3.1 Proposal Working Draft
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 ___
Re: ES3.1 Proposal Working Draft
On Mon, 2008-02-25 at 10:15 +, Mike Cowlishaw wrote: > 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. Surely the Adobe fellows have something to say about this :). Flash tweening and 3D Flash libraries like Papervision3D make extensive use of floating point math. In an environment where tweaks like multiplying fixed points instead of dividing yields substantial performance increases, the "currency calculations" you speak of fade into insignificance. Cheers, -- Nathan de Vries smime.p7s Description: S/MIME cryptographic signature ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Proposal Working Draft
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
Re: ES4 implementation process, teams, and meetings
Brendan Eich wrote: > Thanks for understanding. Now with that in mind, please re-read Jeff's > post and mine. We are talking about working intensively in the next > three months on both specs and implementation. Now is the time to step > up. Apple was /hors de combat/ for a long time in Ecma TC39. Kicking the > legs out from under the table and pointing at the floor is not good > citizenship in my book, whatever our (real) failings in keeping > proto-specs up to date. This is getting a little too belligerent. Maciej has a point which several of us share. For things that haven't been discussed actively, I too have little idea about what their status is or where is the correct place to look for the current understanding of their design. This became a problem when we went from using proposals to relying on individual trac tickets. I think we should go back to maintaining proposals. Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 implementation process, teams, and meetings
I think the important point to keep in mind here is that we need to move forward to sound specs based on commercial implementation. The burden is on those who "understand" the proposals + trac + RI to translate them into implementation and spec for others to evaluate. This is a short step forward for all but the deepest proposals. For the more fundamental changes, the proposal format has and will continue to be unsatisfactory. To address some of the concerns expressed last week, Lars has updated John Resig's ES4 status spreadsheet at http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQ&gid=2 He has added references to some of the materials supporting each feature. We also intend to add a column to indicate the bakedness of each feature. For people who are more interested in self-standing specs, some will be coming in the next few weeks. Jd > -Original Message- > From: [EMAIL PROTECTED] [mailto:es4-discuss- > [EMAIL PROTECTED] On Behalf Of Waldemar Horwat > Sent: Monday, February 25, 2008 5:59 PM > To: Brendan Eich > Cc: Graydon Hoare; es4-discuss@mozilla.org es4-discuss > Subject: Re: ES4 implementation process, teams, and meetings > > Brendan Eich wrote: > > Thanks for understanding. Now with that in mind, please re-read Jeff's > > post and mine. We are talking about working intensively in the next > > three months on both specs and implementation. Now is the time to step > > up. Apple was /hors de combat/ for a long time in Ecma TC39. Kicking the > > legs out from under the table and pointing at the floor is not good > > citizenship in my book, whatever our (real) failings in keeping > > proto-specs up to date. > > This is getting a little too belligerent. > > Maciej has a point which several of us share. For things that haven't > been discussed actively, I too have little idea about what their status is > or where is the correct place to look for the current understanding of > their design. This became a problem when we went from using proposals to > relying on individual trac tickets. I think we should go back to > maintaining proposals. > > Waldemar > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
