[Forwarding a response from Alon Zakai, who is behind Emscripten and
CC'ing him]
>>>  There is also another use-case which has been brought up. As the
>>>  web
>>>  platform is becoming more powerful, people have started converting
>>>  code written for other platforms to javascript+html.
>> By "html", here, do you mean something else than<canvas>?
>> Is there something that compiles any Windows/Mac/Linus UI framework
>> into
>> "HTML5"?
> There is pyjamas that compiles Python into JS and GWT that compiles Java into 
> JS. Both are UI frameworks, and being able to use sync calls in both would be 
> more natural since the original languages have lots of sync stuff I believe. 
> I don't know how important this use case is though. But we would like to 
> compile open source UI frameworks like Qt and GTK into JS using emscripten, 
> and sync would help a lot there.
>
>>>  For example the
>>>  emscipten[1] and mandreel[2] allow recompiling C++ code to
>>>  javascript
>>>  which is then run in a web browser.
>> I've been following loosely this topic and all examples I've seen
>> were
>> either about pure computation (like turning a C GZIP library in JS)
>> or
>> graphics stuffs (using canvas, hence my above question).
>>
>>>  Many times such code relies on APIs or libraries which contain
>>>  blockingcalls.
>> Do you have an example of that? I haven't seen one so far, but that's
>> an
>> interesting point.
>> Specifically, I can't recall having seen any C/C++->JS example that
>> were
>> doing IO (maybe files, but not network),
>> Last I heard, Emscripten compiles to JS from LLVM bytecode. I'm not
>> sure
>> they rely on any library containing blocking calls.
>> But as I said, I have been following that loosely.
> The normal C/C++ IO calls are all synchronous - fopen, fread, etc.
>
> As you said above, this is indeed less of a problem for pure computation. But 
> when compiling a complete game engine for example (like in BananaBread), you 
> need to handle everything a complete app needs, including synchronous IO. 
> Both file IO and and network IO (for multiplayer, downloading assets, etc. - 
> we haven't gotten around to that yet though in BananaBread) are relevant, as 
> well as synchronous GL operations using WebGL.
>
>>>  Technically it might
>>>  be possible to automatically rewrite such code to use asynchronous
>>>  coding patterns, but so far I don't think anyone has managed to do
>>>  that.
>> Naively, I would say, that once we've paid the price to compile code
>> from one language to another, you're not that far off from compiling
>> to
>> a given coding pattern. Especially compiling from LLVM bytecode.
>> Regardless, has anyone tried at all? Has anyone tried to compile to
>> JS+Promises or JS+task.js?
> Consider even the simple and very common case of
>
> ..
> while (!feof(f)) {
>   fread(buf, 100, 1, f);
>   ..process data in buf..
> }
> ..
>
> I don't have any good ideas for something asynchronous to compile this into 
> that does not currently substantially harm performance. Compiling synchronous 
> code into continuation passing style, generators, control flow emulation, or 
> some other async style would greatly reduce performance. In theory JS engines 
> could optimize those styles, but it would be hard and I don't think this is 
> at the top of anyone's list of priorities for any JS engine.
>
> Now, we could say that sync code, mainly IO, will run slowly but that is ok 
> because it's mainly just done during startup. That's true to some extent, but 
> startup is very important too, in BananaBread we already have 5-10 seconds or 
> so to load the entire game engine, a lot of which is file IO and processing, 
> and we have gotten requests to improve that as much as possible because it is 
> very significant for the user's initial impression.
>
> Best,
>   Alon Zakai


Reply via email to