W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Sync API for workers

From: Alon Zakai <alonmozilla@gmail.com>
Date: Tue, 4 Sep 2012 14:25:39 -0700
Message-ID: <CAEX4NpRuTuzA80sGzjY1UCupgQG=2UzhDBh1ZEPmy_UiQjth4A@mail.gmail.com>
To: Brendan Eich <brendan@mozilla.org>
Cc: David Bruant <bruant.d@gmail.com>, Jonas Sicking <jonas@sicking.cc>, "public-webapps@w3.org" <public-webapps@w3.org>
On Tue, Sep 4, 2012 at 1:59 PM, Brendan Eich <brendan@mozilla.org> wrote:
> David Bruant wrote:
>>
>> I can imagine, it sounds hard indeed. Do you have numbers on how it
>> affects performance? Or an intuition on these numbers? I don't need to
>> be convinced that it affects performance significantly, but just to get
>> an idea.
>
>
> This is not going to be easy to estimate, but you might benchmark generator
> vs. non-generator code in the latest SpiderMonkey.
>
> I don't think we need quantification, though. Alon's right, the optimizing
> VMs are not focused on uncommon code other than what's in the dopey
> industry-standard benchmarks.
>

Yes, last I checked generator code is not even JITed. This kind of
problem isn't on the radar of JS engine people - for understandable
reasons, of course.

>
>> I remember that at some point (your JSConf.eu talk last October), in
>> order to be able to compile through Emscripten, the source codebase (in
>> C/C++) had to be manually tweaked sometimes. Is it still the case? If
>> it's an acceptable thing to ask to authors, then would there be easy
>> ways for authors to make their IO blocking code more easily translated
>> to async JS code? I'm pessimistic, but it seems like an interesting
>> question to explore.
>
>
> BananaBread required zero Cube 2 changes, IIRC. Other Emscripten examples
> are also pure compilation.

Yes, we aim at 0 code changes when porting. This is usually the case,
although sometimes something absolutely must be changed. In
BananaBread we changed a few dozen lines of code out of 120,000 for
example.

- azakai
Received on Tuesday, 4 September 2012 22:09:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT