On Aug 30, 2013, at 12:31 PM, Brendan Eich <[email protected]> wrote:
> Thanks for the reply, I'll let SM and V8 peeps speak for themselves (they > retired my SM number ;-). >> Filip Pizlo <mailto:[email protected]> >> August 30, 2013 10:41 AM >> >> On Aug 30, 2013, at 9:28 AM, Brendan Eich <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Hi, >>>> Filip Pizlo <mailto:[email protected]> >>>> August 28, 2013 11:01 PM >>>> Here's the part that gets me, though: what is the value of disallowing >>>> named properties on typed arrays? Who does this help? >>> >>> You've heard about symmetry with struct types (ES6), right? Those do not >>> want expandos. We could break symmetry but at some cost. Too small to worry >>> about? Outweighed by benefits? >> >> It's a fair point. I don't see where it would break semantics but I'll try >> to do a thought experiment to see if it makes things confusing or >> inconvenient to the programmer. Whether or not I care depends on the >> answers to the following questions: >> >> 1) Is the purpose to simplify programming by allowing you to add static >> typing? > > No, we put a stake through that cold heart. > >> 2) Are we trying to help JITs? > > Yes, I think so (SM retirement makes this easy for me to say ;-). Even > excluding type inference as done in SpiderMonkey, just using PICs, structs > over against objects can help JITs avoid boxing values, same as typed arrays > do compared to Arrays. This isn't really a win, at least not for us, anyway. We don't "box" values in the sense of allocating stuff in the heap; we only tag them. The tagging operations are just too darn cheap to worry about getting rid of them. For example, int untagging is basically free. Double untagging is not quite free but our double array inference (for normal JS arrays) is too darn good - you'd have to try quite hard to find a case where using a Float64Array gives you a real win over a JS array into which you only stored doubles. Once exception is that our double array inference for normal JS arrays fails if you store NaN. Our current philosophy towards that is "oh well" - it's not clear that this arises enough that we should care. > > Sometimes you want a product of different types, not a vector of same-typed > elements. Typed arrays were designed so you would alias two views, > crazypants. Structs put on sanepants. Just making sure the use-case has clear > motivation here. OK - by "sanepants" do you mean that there is no weirdo aliasing? Going back to my example of field 'a' aliasing field 'b' - is it possible? > > If so, then the JIT wins implemented today among multiple engines for typed > array element loads and stores will almost certainly be wanted for struct > field traffic too. I think you're being too generous to the typed array optimizations. Vanilla JS arrays are catching up, or have already caught up and surpassed, depending on how you look at it. It sure is tempting to add type thingies to help JITs but I think we're quickly approaching a world where adding primitive types to JS will be a bit like marking your Java methods final in the mistaken belief that it will unlock some extra devirtualization, or marking your variables 'register' in C thinking that this will make your code sooooper fast. > >> 3) Do we just want a sensible way of mapping to binary data? (For both DOM >> and C-to-JS compilers) > > Yes, and don't forget the GPU as well ("DOM" doesn't take that in). Right! I totally buy the native mapping story for struct types. I just don't buy the performance story. ;-) -Filip
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
