Re: Should assigning to out-of-bounds elements of a typed array throw in strict mode code?

2015-02-26 Thread Luke Wagner
Sorry if there was any confusion earlier, but throw-on-OOB semantics is
easier from an AOT/asm.js-compilation POV.  Ideally, typed arrays would
throw on all OOB, but I realize that isn't web compatible at this point.

On Wed, Feb 25, 2015 at 6:40 PM, Jeff Walden wrote:

 Currently, the behavior of IntegerIndexedElementSet is to return false if
 the index being set is outside the array bounds.  This return-false
 directly feeds into the result of [[Set]] on a typed array.  The result is
 that in strict mode code, setting an out-of-bounds array element throws a

 I've heard claims from other SpiderMonkey implementers that this
 requirement makes it difficult to implement high-performance JIT
 optimizations for code that assigns into typed arrays, except in the case
 that the array length is observable in context, the typed array never
 escapes anywhere, its backing ArrayBuffer never escapes anywhere, etc.
 Restrictions that generally aren't very easy to determine with local
 information observable by a JIT.  And while quite often such
 high-performance code isn't strict mode code, it's doubtful that will be
 true far into the future.

 From that point of view, it would be better if IntegerIndexedElementSet
 just returned true in this case -- indicate success without doing
 anything.  What are the compelling reasons to not do this?


es-discuss mailing list

Re: typed array filling convenience AND performance

2014-11-04 Thread Luke Wagner
ArrayBuffer.transfer provides a coarser granularity than the proposed 
ArrayBuffer.prototype.discard in bug 855669.  Page-level madvise(MADV_DONTNEED) 
is the type of thing you'd want if you were implementing a malloc heap 
(jemalloc being an example).  OTOH, ArrayBuffer.transfer also allows you to 
immediately release virtual address space, something discard doesn't, so I 
think these features are complementary.

- Original Message -
 Steve Fink wrote:
  I'm not sure we're talking about the same thing. I'm talking about what
  would be madvise(MADV_DONTNEED) on POSIX or VirtualAlloc(MEM_RESET) on
  Windows. Er... actually, I think it would be MEM_RESET followed by
  MEM_COMMIT to get the zero-filling while still releasing the physical
 Luke should weigh in. I had in mind the words either truncated or
 zero-extended to be newByteLength from
es-discuss mailing list

Re: Holy mixed metaphors, Batman!

2014-10-17 Thread Luke Wagner
FWIW, constellation is a term that some of us have been using for a while (at 
least in Mozilla) for a concept that seems to match Vat.  For example, in the 
context of:
 - when we could have separate task queues on separate threads (as an 
unobservable impl detail to improve responsiveness):
 - which windows' script execution should be blocked by slow-script dialog:

Roughly speaking, a constellation is a set of transitively-reachable windows 
(and, as a special case, workers are their own constellations).  Since 
reachability implies synchronous observable effects, this means all the code in 
all realms in the constellation must use the same event loop.


P.S. A fun corner case to consider is whether cross-origin edges count as 
reachable in the definition of constellation.  I think this boils down to 
whether origin A can (directly or indirectly) trigger (predictable, 
cross-browser, perhaps even standardized) synchronous execution in origin B via 
cross-origin-accessible Window or Location properties.  I was just asking bz 
about this on irc and we need more experimentation to answer this.  Also 
relevant is the 'rel=noreferrer 'target=_blank' requirement to get a new 
(, where 
process is necessarily an over-approximation of constellation (assuming no 
cross-process RPC :).

- Original Message -
 On Fri, Oct 17, 2014 at 6:23 AM, Brendan Eich wrote:
  Again this sub-thread, is mostly about finding the right terms of art. If
  can unify across specs (if not within), that's gravy.
 Vat helps explaining workers, but not the rest.
 es-discuss mailing list
es-discuss mailing list

Re: Rename Number.prototype.clz to Math.clz

2014-01-20 Thread Luke Wagner
It seems to me that we *must* have Math.clz perform ToUint32() on its input.  
Otherwise (if ToInt32() is used), even if the expression is written Math.clz(x 
 0), asm.js/type-inference won't be able to optimize away the 0 branch 
since the ToInt32() in the semantics of Math.clz will convert a large unsigned 
integer argument into a negative integer.

Secondly, I think clz(0) should be 32, not 0:
 - for x86's bsr, since the result is undefined if the input is zero, we need a 
branch or cmov *anyway* to deal with zero.
 - to make up for bsr's shortcomings, newer x86 chips have lzcnt (which JITs 
can emit after testing the right cpuid bit), which defines clz(0) == 32.
 - ARM's clz also defines clz(0) == 32.

The only reason not to do this I could imagine is if there was a de facto 
standard among all x86 chips (such that the JIT could rely on it) to have 
bsr(0) == 0, but I couldn't find any evidence of this.


- Original Message -
 Adam Ahmed wrote:
  Just noting that this actually works:
   Math.ceil(Math.log(0 + 1) / Math.LN2) === 0
  Math.ceil(Math.log(-1 + 1) / Math.LN2) === -Infinity
 That's pretty sweet, but then try -2 or -3 or below and you get NaN.
  Not sure how that affects a Negative NaN-cy option :)
 I think we should make sure (per Jason and Jens) that, given type
 inference or asm.js-style type-checking, we can select a single common
 machine instruction. After that, we should consider more abstract
 prettiness properties such as the one you show for -1. And given the
 -Infinity then NaN inconsistency, perhaps NaN wins. But Jens' point
 about Infinity (bit length in two's complement infinite precision of any
 negative number) is strangely compelling.
 Need to hear from type-inference and asm.js gurus. Cc'ing a few. The
 issue is, given
 where x has inferred type int32, what do we need in the way of a guard
 for negative values? We need something, we cannot use BSR directly
 without getting 32 for -1.
es-discuss mailing list

proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Luke Wagner
Just to be sure, do you agree that both the {lo, hi}-returning API and the 
magic-property API should both be able to achieve equivalent performance on a 
JS engine that has specifically added and optimized these int64 builtins?  I 
think this is true.

Assuming so, the reason to prefer the rather more awkward magic-property API 
would be purely because its polyfill is more efficient.  This is a tough 
choice, but it seems like bending the spec for the polyfill is overly 
conservative in this case.  A lot of the use cases I hear for int64 come from 
crypto and other very specific algorithms which already have implementations in 
JS.  In such cases, it seems like the authors have to write a new version of 
the algorithm using the new builtins anyway so, if performance was important, 
they could just keep around the old version and pick which version to call 
based on whether the new builtins are present.  Or they can just wait until the 
optimization is broadly available before switching.

The other main use case I can think of is large compiled C++ codebases.  
However, in our experience, C++ codebases tend not to heavily use int64 so the 
overhead of the polyfill would be less significant.

Are there any other use cases you have in mind that really demand high polyfill 

API considerations aside, though, I like the idea of bringing fast 64-bit 
arithmetic to JS without waiting for value objects.

es-discuss mailing list