Re: Sync API for workers

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 UTC