-s ASYNCIFY, dosbox

[Александр Гурьянов]

Hi. Trying to compile dosbox with new latest-upstream. It's compiles
without error, but when I run it, I have this error

missing function: emscripten_sleep_with_yield

I just replaced all emterpreter related flags with
-s ASYNCIFY

[Александр Гурьянов]

After replacing emscripten_sleep_with_yield on emscripten_sleep I have
new error:

exception thrown: TypeError: Module.setAsync is not a
function,_emscripten_sleep@http://127.0.0.1:8080/js-dos.js line 1 >
eval:8:182429
GUI_StartUp(Section*)@http://127.0.0.1:8080/js-dos.js line 1 >
WebAssembly.compile:wasm-function[3244]:0x11dccf
Section::ExecuteInit(bool)@http://127.0.0.1:8080/js-dos.js line 1 >
WebAssembly.compile:wasm-function[1025]:0x64869
Config::Init()@http://127.0.0.1:8080/js-dos.js line 1 >
WebAssembly.compile:wasm-function[3634]:0x1339dd
main@http://127.0.0.1:8080/js-dos.js line 1 >
WebAssembly.compile:wasm-function[2183]:0xc6c59
WDOSBOX/Module._main@http://127.0.0.1:8080/js-dos.js line 1 > eval:8:220000
callMain@http://127.0.0.1:8080/js-dos.js line 1 > eval:8:243221
main@http://127.0.0.1:8080/js-dos.js:1:24720
@http://127.0.0.1:8080/index.html:21:9

чт, 18 июл. 2019 г. в 14:47, Александр Гурьянов <caii...@gmail.com>:

[Александр Гурьянов]

I am not sure that I used latest emscripten (through emsdk), don't
know how to check.

emcc (Emscripten gcc/clang-like replacement) 1.38.37 (commit
d33f7a29002a2463a7956cd53a559b97a52f9560)
Copyright (C) 2014 the Emscripten authors (see AUTHORS.txt)
This is free and open source software under the MIT license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

My debug log didn't contain wasm-opt --asyncify which should be I think.

Btw, I used this to update emscripten:
emsdk update-tags && emsdk install latest-upstream && emsdk activate
-embedded latest-upstream

чт, 18 июл. 2019 г. в 14:52, Александр Гурьянов <caii...@gmail.com>:

[Alon Zakai]

You may need to do "emsdk update" instead of "emsdk update-tags", depending on if you get the emsdk using git or not.

Latest version should be 1.38.39.

About those errors - yes, the APIs for old Asyncify, Emterpreter, and new Asyncify are not identical. Emterpreter has the "yield" concept, which is not needed in Asyncify (so as you said, just call emscripten_sleep instead of _with_yield). Module.setAsync is an internal API of old Asyncify - if you have custom JS code using it, you need to update it to the new Asyncify's API (see notes on handleSleep in the blogpost: https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html ).

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVG2PF2MET9GXVeRZTGvSTMMRa5RtawkzMRYvO6rvo1T-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Александр Гурьянов]

Works like a charm! Even file size is smaller on 300Kb (2.8Mb instead
of 3.1Mb), have only two questions:
- Is Asyncify have simmilar conecpt of normal state like emterpreter
(EmterpreterAsync.state === 0)?
- Is EMTERPRETIFY_WHITELIST (list of functions that neet to be
emterpret) can be useful for Asyncify? I tried -s
ASYNCIFY_IGNORE_INDIRECT output size is 1,8M, but didn't work

чт, 18 июл. 2019 г. в 23:28, Alon Zakai <alon...@gmail.com>:

> To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSciPtuE4ry3V108OC9iZfy4%2BeEvrCYfd2Ht9UTm%2BPrtA%40mail.gmail.com.

[Alon Zakai]

On Thu, Jul 18, 2019 at 11:52 PM Александр Гурьянов <caii...@gmail.com> wrote:

Works like a charm! Even file size is smaller on 300Kb (2.8Mb instead
of 3.1Mb)

Great!

- Is Asyncify have simmilar conecpt of normal state like emterpreter
(EmterpreterAsync.state === 0)?

Yes, there is Asyncify.state, and 0 means "normal" there too.

- Is EMTERPRETIFY_WHITELIST (list of functions that neet to be
emterpret) can be useful for Asyncify? I tried -s
ASYNCIFY_IGNORE_INDIRECT output size is 1,8M, but didn't work

We are considering that, see

https://github.com/WebAssembly/binaryen/issues/2218

But the overhead tends to be fairly small, and I hope we can optimize it more without adding manual lists.

Sounds like you see a 55% code size increase - I'm also curious what is the slowdown, if you can measure that?

- Alon

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVFt2fLPxnZJLoapy3WoLP7Yt%2Ba85SthTLPktwRsfCoJHw%40mail.gmail.com.

[Александр Гурьянов]

Just updated js-dos to latest upsteram, now you can compare performance:
http://js-dos.com/6.22/64k/index.html - for Asyncify
http://js-dos.com/6.22/64k/index-fastcomp.html - for Emterpreter

In FF performance is same, but in Chrome asyncify version looks
significant slowly. Please give a try.

пт, 19 июл. 2019 г. в 20:43, Alon Zakai <alon...@gmail.com>:

> To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQsNRR1ydC4GLVjjkYvjJ8Z5R%3DaF4FSLzYXUPRqwMao7w%40mail.gmail.com.

[Александр Гурьянов]

Even digger works very poor here http://js-dos.com/ (in chrome). I
just changed emscripten_sleep_with_yield with emscripten_sleep and
that's all. Don't know why Chrome goes crazy.

пн, 22 июл. 2019 г. в 18:04, Александр Гурьянов <caii...@gmail.com>:

[Александр Гурьянов]

I am sorry guys, my estimation of sizes/preformance was wrong.

Ubuntu 19.04 / Chrome 72.0.3626.121

O3:
DEFAULT 2.0Mb 60 FPS / 22 FPS
EMTERPRETIFY 2.2Mb 60 FPS / 40 - 50 FPS
ASYNCIFY 3.0Mb 44-55 FPS / 11 - 44 FPS

Oz:
DEFAULT 1.8Mb 55-60 FPS / 22 FPS
EMTERPRETIFY 2.1Mb 55-60 FPS / 22 - 47 FPS
ASYNCIFY 2.8Mb 50-60 FPS / 13 - 35 FPS

NOTES:
- First fps number is for single dosbox instance on page (index.html?game=0)
- Second fps number is for 9 dosbox instances on page (index.html)
- Default version used emscripten_set_main_loop, I think low fps for 9
instances is because stats.js can't calculate it correctly, cause
everything work very smooth in Default mode.
- In FF every version works near 60 FPS, but game expirence is not
same (need to find better metric then FPS)

From my point of view, ASYNCIFY is slower on ~10 FPS I tried to do
basic profiling but didn't find any spikes. I think this slowness is
related to bigger file size. Hope, option like EMTERPRETIFY_WHITELIST
can solve this problem.
ASYNCIFY have dramatic slow down (against emterpreter {in chrome?})
when you run multiple instance of same app on single page (maybe there
is some synchronization or inside chrome).

I swithced to emterpreter, becaue for now it's better. You can try
this test here:
ASYNCIFY:
http://js-dos.com/6.22/64k/index-upstream.html?game=0 (1 game)
http://js-dos.com/6.22/64k/index-upstream.html
EMTERPRETIFY:
http://js-dos.com/6.22/64k/index-fastcomp.html?game=0 (1 game)
http://js-dos.com/6.22/64k/index-fastcomp.html

Also you can download binaries here:
https://github.com/caiiiycuk/js-dos/tree/gh-pages/6.22/latest-fastcomp
https://github.com/caiiiycuk/js-dos/tree/gh-pages/6.22/latest-upstream

Where

пн, 22 июл. 2019 г. в 18:15, Александр Гурьянов <caii...@gmail.com>:

[Александр Гурьянов]

wdosbox.wasm.js - is wasm binary
wdosbox.js.symbols - symbols

вт, 23 июл. 2019 г. в 12:03, Александр Гурьянов <caii...@gmail.com>:

[Alon Zakai]

Thanks, great testcase!

Are those links going to remain up? I'll file a chromium bug if so, as I also see the chrome performance on asyncify as slower than I'd expect.

Otherwise I looked into the code, and most of the itime is spent inside a single huge function that asyncify has modified. Perhaps the main interpreter loop? It's hard to see more optimization opportunities there. I think that means we need a whitelist like in emterpreter. Btw, did you use the whitelist or blacklist there - which would be better?

- Alon

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVEqX2W0Kvym32VYfBqPu6qXMzrffkQEXfaNWs2yCLciQQ%40mail.gmail.com.

[Александр Гурьянов]

Yes this links will be live as long as needed.

> Otherwise I looked into the code, and most of the itime is spent inside a single huge function that asyncify has modified. Perhaps the main interpreter loop? It's hard to see more optimization opportunities there.

Yes I think you right, it's dosbox main loop (__ZL11Normal_Loopv).

> Btw, did you use the whitelist or blacklist there - which would be better?

I used white list
https://github.com/caiiiycuk/js-dos/blob/6.22/js-dos-cpp/emterpretify.txt

ср, 24 июл. 2019 г. в 01:26, Alon Zakai <alon...@gmail.com>:

> To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpS_v24602kd5t1mm9MkAaj4LydBmFc7xi%2BnAck4nZzNXw%40mail.gmail.com.

[Alon Zakai]

Great, thanks caiiiycuk!

- Alon

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVHOLtp%2B4yyzCP9VZPHvddo-JNF4De_5PTUx-vFKTUccpg%40mail.gmail.com.

[caiiiycuk]

Just want to summarize everything after adding WHITELIST support:

Ubuntu 19.04 / Chrome 72.0.3626.121

O3:
DEFAULT                        2.0Mb      60 FPS       / 22 FPS
EMTERPRETIFY             2.2Mb      60 FPS       / 40 - 50 FPS
ASYNCIFY                      3.0Mb      44-55 FPS  / 11 - 44 FPS

ASYNCIFY_WHITELIST  2.1Mb       60 FPS      /  44 - 48 FPS

Oz:
DEFAULT                        1.8Mb       55-60 FPS  / 22 FPS
EMTERPRETIFY             2.1Mb       55-60 FPS  / 22 - 47 FPS
ASYNCIFY                      2.8Mb       50-60 FPS  / 13 - 35 FPS

ASYNCIFY_WHITELIST  1.8Mb       60 FPS       /  48-50 FPS

After applying WHITELIST, the size of binary is little bit smaller, and perfromance is same or better. Nice result.