Alon, thanks for clarification. Floh, very interesting!
> What are you using the asyncify changes for? Just for "slicing up" the > execution loop into frames, or also for other things? I am using it just for slicing, to prevent browser freeze. I think that emulation flow of js-dos is very similar: - emulation and rendering happens inside infinite loop. Function of this loop can call it self recursively, this is reason why it's not easy to use emscripten frame callback instead of asyncify. So this loop is paused by asyncify each 16ms (1 frame), and then resumes execution with post message call. setTimeout is not so effective (min interval is 4ms). This execution flow have simmilar performance that emulation through emscripten frame callback. - inside each frame js-dos tries to emulate N instructions. This N is defined config or can be calculated automatically based on host performance. Of course real count of emulated instructions is clamped to fit 16 ms interval. In "auto" mode, js-dos used simple algorithm to compare how many instructions is executed and increase of decrease N dynamically. - emulation updates SDL pixel buffer, that rendered to canvas. updates is smart, only changed parts are updated (not sure that it's have effect on emscripten sdl implementation, guess all canvas is updated each time) - sound emulation is made by sdl mixer callback, again it's memory buffer that updated each frame, and pushed to emscripten sdl implementations (which used AudioNode). this is not very good, sometimes sound can lag. - mouse and keyboard input are made through emscripten sdl impelementation. Actually, I really want to drop SDL and replace it with something ligther like your sokol abstraction. Not sure that it will give better performance, but I think code will be much easier to understand. To do this I plan to add messages abstraction, to have chance to switch to workers/WASI env if needed. I also have no idea how to increse performance more. Original dos box have "dynamic core" that recompiles program to host CPU (x86), but it used a lot of assembler code, that can't be compiled with WebAssembly, and I don't understand it very well yet. Maybe there is some way to make "dynamic core" for WebAssembly. Also, do you think that future SMID support can increase performance of emulator? All emulated cpu instructions are emulated one by one, so looks SMID is also useless. пт, 17 янв. 2020 г. в 00:35, Alon Zakai <[email protected]>: > > About WASI, it doesn't have graphics/audio/mouse input etc. APIs yet, so it's > probably too early to port something like DOSBox? Unless you create a custom > embedding, but that would be a lot of work. > > About performance, unless iOS supports some form of native WASI VM in a > special way, I think you'd need to ship your own VM in your app. And I > believe they prevent JIT compilation in such a case, so it would be slower > compared to the browser (unless there is a working solution for AOT > compilation perhaps? I'm not aware of a robust one yet). > > On Wed, Jan 15, 2020 at 5:22 AM Александр Гурьянов <[email protected]> > wrote: >> >> Hi guys. I working on next version of js-dos, and I have some ideas >> where to go. I have couple questions to see which way is better. >> >> Currently, js-dos is a WebAssembly binary (+asyncify changes) that >> does emulation in 16ms frames, and stops with emscripten_sleep for >> processing user input. So typical work flow is: >> >> 16ms emulation| <process user input> | 16ms emulation | <process user >> input> | etc. >> >> Typically <user input> is empty, and performance is limited by browser >> performance, and browser scheduler that stops emulation with >> emscripten_sleep. >> >> My first question is: >> 1. "Can I have any performance boost if I move emulation core inside worker?" >> >> From my point of view it's not sens, because even in worker I should >> stop emulations every 16ms to process messages and send updates to >> page. Even If I do not account frames data (320x200 32bpp image), I >> think performance will be same as in regular integration. Am I wrong? >> >> My second questing: >> 2. "Is WASI perfromance is better than default WebView WebAsssembly >> core?" (android/ios) >> >> One of my target is provide js-dos also on mobiles (android/ios) and I >> think I can do it as is, or also I can do it with WASI. I think with >> WASI clients can integrate js-dos in more ways, but what about >> performance? Is it more preformant to use WASI instead of browser on >> mobiles, or they are same? >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVFLTVLCiF6QnQWe7tg666Q8ni1jXb3yUbAYcT38ED7Sow%40mail.gmail.com. > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpR%3Di102C76Gp2NeDbHGv93j_XDgRW_EnEOSVoBX_h5diQ%40mail.gmail.com. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVG3ci_Ur97c0CeneQk_R9r0AL%2BMZrbYCNEUObfe8E-PhQ%40mail.gmail.com.
