headers
Alta27Roy | 3 Feb 14:41

Re: single-threaded JSRuntime

freelance writer
Permalink | Reply | 0 comments |
headers
Anders Feder | 3 Feb 13:44
Picon

Building SpiderMonkey with Android NDK toolchain

Hi,

I am porting a game using SpiderMonkey to Android. Because I need to
integrate with the game's existing build system, I have to build
SpiderMonkey using the Android NDK standalone toolchain, not the ndk-
build tool. Can anyone please tell me how to accomplish this?

I can see that SpiderMonkey's configure has an --with-android-
toolchain=DIR option, but I am unsure how to use it - specifically,
which other options I need to combine it with?

Thank you.

Anders Feder
Permalink | Reply | 1 comment |
headers
Dave Mandelin | 3 Feb 19:09

Re: Making Spidermonkey Parser API Available to JS_CompileFile()

On Jan 27, 9:04 am, Masquerade <msqwe...@yahoo.com> wrote:
> When I use the stand alone Spidermonkey shell to load and execute a
> javascript source file by the load() function call,  the
> Reflect.parse() global object/function is available.  But when I
> compile the same javascript src by the JSAPI function
> JS_CompileFile(), the Reflect object is undefined.
>
> How do we enable the Reflect object when using the standard JSAPI
> compilation functions?

I think you need to do this on your global object:

        if (!JS_InitReflect(cx, glob))
            return NULL;

It's not on MDN but I found it by looking in js.cpp.

Dave
Permalink | Reply | 0 comments |
headers
sloisel | 4 Feb 18:24
Picon
Picon

Apparent poor performance with some sparse Array uses

Dear Mozilla js developers,

I have discovered a poor performance case for v8 as well as Firefox
and the other browsers. My intuition is that this poor performance is
caused by the use of lots of moderately sparse Arrays. I discovered
this while implementing standard numerical analysis routines. For
most
of my routines, I can get 50-300MFLOPS (millions of floating points
instructions per second), which is not too bad (C would yield some
GFLOPS). When I started implementing sparse linear algebra, the use
of
sparse Arrays was natural. However, I found that, at least when the
sparse Arrays get a little bit dense, the FLOP rate is only about
1-2MFLOPS.

In order to show this behavior in a self-contained example, I've made
a self-contained benchmark here: http://jsperf.com/sparse-array-performance

What do you think?

Thanks,

Sébastien Loisel
Permalink | Reply | 7 comments |
headers
Boris Zbarsky | 7 Feb 06:10
Picon
Favicon

Re: Apparent poor performance with some sparse Array uses

On 2/4/12 12:24 PM, sloisel wrote:
> In order to show this behavior in a self-contained example, I've made
> a self-contained benchmark here: http://jsperf.com/sparse-array-performance

I just looked at this testcase in a profiler, and a huge chunk of the 
time seems to be spent calling Math.abs() on objects.  Specifically on 
array objects.  This forces conversion of the array to a string, then of 
that string to a number, then evaluation of Math.abs() on that number. 
Over 60% of the time is spent on this.

Presumably that's coming from this line:

   if(abs(U[i]) >= tol*abs(U[j])) { j = i; }

Elsewhere in the script, U is treated as an array of arrays.  What were 
you actually trying to do with this line?

The other thing that I see that's slow is your use of "for (x in A)" to 
iterate arrays.  That's actually broken; it can iterate more than just 
the indexed properties of the array.  It's also much slower than an 
explicit iteration from 0 to length, for various reasons.

There's also some weirdness going on with uncached calls, but that may 
be due to the issues above.

Finally, the use of getOwnProperty is probably pretty slow; 3-4% of the 
time is spent there.  Not sure that any of the replacements would be 
much faster for a sparse array, though...

The other things taking up time do in fact seem to have to do with
(Continue reading)

Permalink | Reply | 5 comments |
headers
a.catel | 7 Feb 06:25

Re: Apparent poor performance with some sparse Array uses


May I add this :
http://people.mozilla.com/~dmandelin/KnowYourEngines_Velocity2011.pdf
(page 49) 

On Tue, 07 Feb 2012 00:10:19 -0500, Boris Zbarsky wrote: 

>
On 2/4/12 12:24 PM, sloisel wrote:
> 
>> In order to show this behavior
in a self-contained example, I've made a self-contained benchmark here:
http://jsperf.com/sparse-array-performance [1]
> 
> I just looked at
this testcase in a profiler, and a huge chunk of the 
> time seems to be
spent calling Math.abs() on objects. Specifically on 
> array objects.
This forces conversion of the array to a string, then of 
> that string
to a number, then evaluation of Math.abs() on that number. 
> Over 60%
of the time is spent on this.
> 
> Presumably that's coming from this
line:
> 
> if(abs(U[i]) >= tol*abs(U[j])) { j = i; }
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boris Zbarsky | 7 Feb 06:40
Picon
Favicon

Re: Apparent poor performance with some sparse Array uses

On 2/7/12 12:10 AM, Boris Zbarsky wrote:
> The other thing that I see that's slow is your use of "for (x in A)" to
> iterate arrays. That's actually broken; it can iterate more than just
> the indexed properties of the array. It's also much slower than an
> explicit iteration from 0 to length, for various reasons.

Ah, though I guess for a sparse array iterating up to length will be 
slower, and you end up making the hasOwnProperty calls to deal with the 
"broken" part above.

It really feels like there should be a better way to do this.  I wonder 
whether grabbing Object.keys on the array and then going from 0 to 
length on that would work better....  You might end up with lots of int 
to string conversions, but you might end up with those anyway.

-Boris
Permalink | Reply | 2 comments |
headers
Dave Mandelin | 6 Feb 21:46

Re: Apparent poor performance with some sparse Array uses

On Feb 4, 9:24 am, sloisel <s.loi...@hw.ac.uk> wrote:
> Dear Mozilla js developers,
>
> I have discovered a poor performance case for v8 as well as Firefox
> and the other browsers. My intuition is that this poor performance is
> caused by the use of lots of moderately sparse Arrays. I discovered
> this while implementing standard numerical analysis routines. For
> most
> of my routines, I can get 50-300MFLOPS (millions of floating points
> instructions per second), which is not too bad (C would yield some
> GFLOPS). When I started implementing sparse linear algebra, the use
> of
> sparse Arrays was natural. However, I found that, at least when the
> sparse Arrays get a little bit dense, the FLOP rate is only about
> 1-2MFLOPS.
>
> In order to show this behavior in a self-contained example, I've made
> a self-contained benchmark here:http://jsperf.com/sparse-array-performance
>
> What do you think?

My first thought is that in my experience, JS sparse arrays are
usually about 5-100x slower than dense arrays, which sounds in line
with what you are saying.

In all JS engines (that I'm aware of), if you create a sparse array
with many elements, you'll get something like (1) an 'elements' array
that holds the values in the order you created them (i.e., by a[i] =
x), (2) an array or a linked list of properties, which maps names to
indexes in the elements array, and (3) a hashmap or other such index
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zack Weinberg | 7 Feb 07:27
Picon
Gravatar

Re: Apparent poor performance with some sparse Array uses

On 2012-02-06 9:40 PM, Boris Zbarsky wrote:
> On 2/7/12 12:10 AM, Boris Zbarsky wrote:
>> The other thing that I see that's slow is your use of "for (x in A)" to
>> iterate arrays. That's actually broken; it can iterate more than just
>> the indexed properties of the array. It's also much slower than an
>> explicit iteration from 0 to length, for various reasons.
>
> Ah, though I guess for a sparse array iterating up to length will be
> slower, and you end up making the hasOwnProperty calls to deal with the
> "broken" part above.
>
> It really feels like there should be a better way to do this. I wonder
> whether grabbing Object.keys on the array and then going from 0 to
> length on that would work better.... You might end up with lots of int
> to string conversions, but you might end up with those anyway.

It sure would be nice if "for (x in A)" was the most efficient and 
correct way to iterate over arrays as well as the most obvious.

zw
Permalink | Reply | 1 comment |
headers
Masquerade | 7 Feb 10:17
Picon
Favicon

Preventing Decompilation

I would like to use Spidermonkey as the scripting engine of my own
product.  I need to allow users of my product to distribute compiled
script source in binary format that cannot be decompiled easily for
copyright protection.

Currently, my understanding is that I need to XDR the compiled
JSScriptObject() and add my own encryption to it the binary output.
But I also found that the internal JSScript object already contains
information like source notes that allow people to decompile the
scripts.  These source notes seem to be included in the XDR binary
output so reloading an XDR image would simply regenerate the decompile
information for a hacker to see.  Can we remove these source notes
information directly from the JSScript object?  Is there any other
legitimate functionality other than decompilation that depends on the
availability of source notes?
Permalink | Reply | 0 comments |

Gmane