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: ES3.1 Proposal Working Draft
On Feb 20, 2008, at 1:25 PM, Mark S. Miller wrote: What numbers are representable as double but not decimal? Mike Cowlishaw's page at http://www2.hursley.ibm.com/decimal/ is extremely informative, especially http://www2.hursley.ibm.com/decimal/ decifaq.html; see also the link to http://grouper.ieee.org/groups/754/. See http://www2.hursley.ibm.com/decimal/decifaq6.html#bindigits and http://www2.hursley.ibm.com/decimal/decifaq6.html#binapprox for double to decimal conversion answers. As http://wiki.ecmascript.org/ doku.php?id=proposals:decimal summarizes: * A very small amount of precision which may be present in a double- precision binary fp number is lost during a double → decimal promotion, but that: o No precision is lost in an integral → decimal promotion. o Reading a numeric lexeme as a decimal preserves more precision than reading it as a double. Does decimal have NaN, Infinity, -Infinity, Yes -- from the ES4 RI: -1.0m/0.0m -Infinity 1.0m/0.0m Infinity 0.0m/0.0m NaN and -0.0? Yes: 1.0m/-0.0m -Infinity (Btw, I never liked -0.0. And I especially dislike ES3's behavior that 0.0 === -0.0. However, I would argue against making incompatible changes to this.) Guy Steele edited Edition 1 of ECMA-262 and argued for both of these parts of the standard, based on precedent in related programming languages, as well as advice in IEEE-754 itself. He pointed out something important to numerical programmers: you can walk around the four quadrants using signed zeros with atan2: js Math.atan2(0,0) 0 js Math.atan2(-0,0) 0 js Math.atan2(-0,-0) -3.141592653589793 js Math.atan2(0,-0) 3.141592653589793 /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Proposal Working Draft - decimal support
OK, thanks (also for the archive pointer). Mike - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Mike Cowlishaw, IBM Fellow IBM UK (MP8), PO Box 31, Birmingham Road, Warwick, CV34 5JL mailto:[EMAIL PROTECTED] -- http://www2.hursley.ibm.com/mfcsumm.html Brendan Eich [EMAIL PROTECTED] 21/02/2008 09:54 To Mike Cowlishaw/UK/[EMAIL PROTECTED] cc Adam Peller [EMAIL PROTECTED], es4-discuss@mozilla.org es4-discuss es4-discuss@mozilla.org Subject Re: ES3.1 Proposal Working Draft - decimal support On Feb 21, 2008, at 1:25 AM, Mike Cowlishaw wrote: Separately from the decimal discussion, I am a bit confused at how ES3.x or ES4 is migrated to from ES3. If the syntax cannot change then that implies that the semantics change without any indication in the syntax. ES4 has new syntax; the syntax-cannot-change has been an on-then-off- then-on-again principal for ES3.1. In particular ES4 has the m suffix for decimal literals, and it has had some kind of 'use decimal' pragma. That would mean that existing scripts would work differently than before. Surely that pretty much requires some meta-notation (such as opt-in versioning)? Indeed. /be 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 Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Proposal Working Draft - decimal support
On Feb 21, 2008, at 1:25 AM, Mike Cowlishaw wrote: Separately from the decimal discussion, I am a bit confused at how ES3.x or ES4 is migrated to from ES3. If the syntax cannot change then that implies that the semantics change without any indication in the syntax. ES4 has new syntax; the syntax-cannot-change has been an on-then-off- then-on-again principal for ES3.1. In particular ES4 has the m suffix for decimal literals, and it has had some kind of 'use decimal' pragma. That would mean that existing scripts would work differently than before. Surely that pretty much requires some meta-notation (such as opt-in versioning)? Indeed. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Proposal Working Draft
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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Proposal Working Draft
Each of us has some pet addition we think would be a great addition to the language. const, decimal, getters and setters, destructing assignment -- all these have come up just this morning!. Each of these makes the language larger and more complex, imposing a general diffuse cost on everyone. Mark, as I recall, the discussion at the March meeting in Newton involved implementing decimal arithmetic in ES3.1 to *replace* the floating point implementation in ES3, thus no new syntax. Yes, this would have unexpected results for those who actually have code logic which expects a value of 46.19 pounds, in Mike's example (see Numbers thread) but the benefits here seemed to far outweigh this discrepancy. I can't speak to the technical level of detail that Mike can, but at a high level it's seen as a bug by the vast majority of users, and for all practical purposes, that's what it is.___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Proposal Working Draft
2008/2/20 Adam Peller [EMAIL PROTECTED]: Mark, as I recall, the discussion at the March meeting in Newton involved implementing decimal arithmetic in ES3.1 to *replace* the floating point implementation in ES3, thus no new syntax. Yes, this would have unexpected results for those who actually have code logic which expects a value of 46.19 pounds, in Mike's example (see Numbers thread) but the benefits here seemed to far outweigh this discrepancy. I can't speak to the technical level of detail that Mike can, but at a high level it's seen as a bug by the vast majority of users, and for all practical purposes, that's what it is. I was not at the March meeting. If decimal is sufficiently compatible with binary double precision floating point to keep old programs working, I might be willing to consider *replacing* double with decimal. How compatible are they? What numbers are representable as double but not decimal? Does decimal have NaN, Infinity, -Infinity, and -0.0? (Btw, I never liked -0.0. And I especially dislike ES3's behavior that 0.0 === -0.0. However, I would argue against making incompatible changes to this.) The other design constraint is that ES4 be a compatible superset of ES3.1. In light of your message, I checked the ES4 wiki pages. http://wiki.ecmascript.org/doku.php?id=proposals:numberss=decimal seems to imply that use of ES3 syntax for numbers is to be interpreted (approximately) according to ES3 rules. Are the ES4 folks willing to *replace* binary floating point with decimal and drop the decimal literal syntax? If not, then I don't see how we could allow decimal into ES3.1. -- Cheers, --MarkM ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Proposal Working Draft
On Feb 20, 2008, at 1:00 PM, Adam Peller wrote: Each of us has some pet addition we think would be a great addition to the language. const, decimal, getters and setters, destructing assignment -- all these have come up just this morning!. Each of these makes the language larger and more complex, imposing a general diffuse cost on everyone. Mark, as I recall, the discussion at the March meeting in Newton involved implementing decimal arithmetic in ES3.1 to *replace* the floating point implementation in ES3, thus no new syntax. Yes, this would have unexpected results for those who actually have code logic which expects a value of 46.19 pounds, in Mike's example (see Numbers thread) but the benefits here seemed to far outweigh this discrepancy. I can't speak to the technical level of detail that Mike can, but at a high level it's seen as a bug by the vast majority of users, and for all practical purposes, that's what it is 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 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. - Maciej ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Proposal Working Draft
On Feb 20, 2008, at 1:00 PM, Adam Peller wrote: Each of us has some pet addition we think would be a great addition to the language. const, decimal, getters and setters, destructing assignment -- all these have come up just this morning!. Each of these makes the language larger and more complex, imposing a general diffuse cost on everyone. Mark, as I recall, the discussion at the March meeting in Newton involved implementing decimal arithmetic in ES3.1 to *replace* the floating point implementation in ES3, thus no new syntax. Yes, this would have unexpected results for those who actually have code logic which expects a value of 46.19 pounds, in Mike's example (see Numbers thread). Hi Adam, Mike: I'm not sure what was to blame for that Machester car-park example -- IEEE double can multiply 4.2 by 11 and round properly: js 11*4.2 46.2 js (11*4.2).toFixed(2) 46.20 Cc'ing Mike in case he knows the full story (it's a fun example and useful real-world evidence of something, I bet). but the benefits here seemed to far outweigh this discrepancy. No, sorry -- too much real-world code, not to mention synthetic benchmarks, depend on hardware-implemented floating point. There are also enough numerical and semi-numerical JS apps around that count on IEEE-754 double precision quirks that we cannot change the number type without opt-in versioning. Anyway, the idea of ES3.1 as I understand it (and at least Mark Miller agrees) is not to promulgate a new, incompatible version with a distinct MIME type (including version= parameter). ES3.1, everyone involved at the last Ecma TC39 meeting seemed to agree, could be done as an Ecma TR (Technical Report). I'm against it becoming the next (4th) edition and making its way to ISO, especially if it has few changes from ES3, and I believe others involved in TC39 are also opposed to that. Being vague about 3.1 possibly including ES4 features is a sure way to delay both any useful 3.1 TR and the full ES4, which is now entering a multiple-interoperating-implementations phase of standardization. If we have to keep monitoring and arguing about what's in 3.1 that might not be exactly the same in 4, to preserve the 3.1 4 subset relation, we all lose (by my definition of lose). I can't speak to the technical level of detail that Mike can, but at a high level it's seen as a bug by the vast majority of users, and for all practical purposes, that's what it is. Yes, I keep reciting its status as the most duplicated JavaScript Engine bug on file at https://bugzilla.mozilla.org/ (to wit, https:// bugzilla.mozilla.org/show_bug.cgi?id=5856). But that does not mean it can be fixed with an incompatible change. The thinking for ES4 was to support a 'use decimal' pragma, for block- or wider-scoped explicit opt in. This proposal, http://wiki.ecmascript.org/doku.php?id=proposals:decimal with this discussion page http://wiki.ecmascript.org/doku.php?id=discussion:decimal stood for a while, but was superseded by http://bugs.ecmascript.org/ticket/222 And I believe there was an email conversation or two in which Mike was included. At this point, I would find it helpful to summarize the thinking on usable alteratives for decimal in ES4, and try to reach a consensus in this list. But again, I do not believe we can change the number type incompatibly -- that ship sailed in 1995. :-( /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
