ASM.JS status for upstream backend
71 views
Skip to first unread message
Александр Гурьянов
Nov 2, 2019, 11:52:39 AM11/2/19
to emscripte...@googlegroups.com
Hi, from docs:
```
WASM=0 behaves differently in the two backends. In fastcomp we emit
asm.js, while in upstream we emit JS (since not all wasm constructs
can be expressed in asm.js). Also, the JS support implements the same
external WebAssembly.* API, so in particular startup will be async
just like wasm by default, and you can control that with
WASM_ASYNC_COMPILATION (even though WASM=0).
```
Do you have plan to add support for ASM.JS in non-fastcomp backend? I
received feedback that js version of js-dos is much slower then asm.js
version of it.
I have 3 version of js-dos now:
* asyncify
* emterp
* nosync
So for nosync & emterp version I can compile ASM.JS with fastcomp. Can
I also compile asyncify version with fastcomp to asm.js?
```
WASM=0 behaves differently in the two backends. In fastcomp we emit
asm.js, while in upstream we emit JS (since not all wasm constructs
can be expressed in asm.js). Also, the JS support implements the same
external WebAssembly.* API, so in particular startup will be async
just like wasm by default, and you can control that with
WASM_ASYNC_COMPILATION (even though WASM=0).
```
Do you have plan to add support for ASM.JS in non-fastcomp backend? I
received feedback that js version of js-dos is much slower then asm.js
version of it.
I have 3 version of js-dos now:
* asyncify
* emterp
* nosync
So for nosync & emterp version I can compile ASM.JS with fastcomp. Can
I also compile asyncify version with fastcomp to asm.js?
Alon Zakai
Nov 2, 2019, 1:10:37 PM11/2/19
to emscripte...@googlegroups.com
I don't have plans to work on asm.js for the upstream backend. (If someone else is, though, I'm not opposed to patches.)
The key issues are that almost all browsers have wasm anyhow so the JS build matters less and less, and that an increasing number of wasm features can't work in asm.js anyhow. So asm.js would only help a small and decreasing number of old browsers, and in a decreasing subset of wasm.
Where do you currently use the JS version of js-dos?
You can still use fastcomp, but we've removed Asyncify there as Emterpreter has worked there for a long time, and upstream Asyncify is now stable as well. But an older fastcomp version (1.38.40 or older) still has it.
- Alon
--
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%3DVGGbZvypXnN2HUDSXi%2Bi2j_fhK2SSGuG2xpE1u%2Bud_c8g%40mail.gmail.com.
Александр Гурьянов
Nov 3, 2019, 1:22:17 AM11/3/19
to emscripte...@googlegroups.com
I totaly agree with this approach. I used js just to support Internet
Explorer, so it's not very important. I will provide asm.js for nosync
and emterp version, and play js for asyncify even if it's slower.
вс, 3 нояб. 2019 г. в 00:10, Alon Zakai <alon...@gmail.com>:
> To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTkJX4jCF%2Bi_0j6Bc-vg3T55XvZcaM5oKFiUxK3dcX3HQ%40mail.gmail.com.
Explorer, so it's not very important. I will provide asm.js for nosync
and emterp version, and play js for asyncify even if it's slower.
вс, 3 нояб. 2019 г. в 00:10, Alon Zakai <alon...@gmail.com>:
Sam Clegg
Nov 14, 2019, 8:44:32 PM11/14/19
to emscripte...@googlegroups.com
On Sat, Nov 2, 2019 at 10:22 PM Александр Гурьянов <caii...@gmail.com> wrote:
>
> I totaly agree with this approach. I used js just to support Internet
> Explorer, so it's not very important. I will provide asm.js for nosync
> and emterp version, and play js for asyncify even if it's slower.
>
Are there versions of IE that have asm.js acceleration but no wasm
>
> I totaly agree with this approach. I used js just to support Internet
> Explorer, so it's not very important. I will provide asm.js for nosync
> and emterp version, and play js for asyncify even if it's slower.
>
support? i.e. is asm.js really faster than wasm2js on that platforms
where you *need* to run JS?
Александр Гурьянов
Nov 14, 2019, 9:58:29 PM11/14/19
to emscripte...@googlegroups.com
> i.e. is asm.js really faster than wasm2js on that platforms where you *need* to run JS?
If browser didn't support asm.js then plain js have same performance
level. But for sure, if browser support asm.js, then asm.js have much
much better performance.
Regarding to you question, I understand your point, but as js-dos
maintainer I should provide must optimized version for each
environment (e.g. wasm, asm.js).
Form real use case, I only used asm.js for fallbacking ios safari,
because sometimes it can't start wasm version with "out of execution
memory" error (not js-dos case).
Anyway, my feedback is that wasm+asynicify version is most performant
and stable version, that should be used most time.
I don't know why but it even more faster then wasm no async version.
пт, 15 нояб. 2019 г. в 08:44, 'Sam Clegg' via emscripten-discuss
<emscripte...@googlegroups.com>:
Shachar Langbeheim
Nov 15, 2019, 2:45:52 AM11/15/19
to emscripten-discuss
"
Anyway, my feedback is that wasm+asynicify version is most performant
and stable version, that should be used most time."
and stable version, that should be used most time."
That's an interesting take. Could it be because it works on a separate worker, and so isn't polled by the JS event loop?
And can you estimate the performance change with and without asyncify?
And can you estimate the performance change with and without asyncify?
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVFqA871W4ppbscDb%3DT4fHDzjSc9UsYYwXRcWokcc%3D9-hw%40mail.gmail.com.
Sam Clegg
Nov 15, 2019, 12:49:09 PM11/15/19
to emscripte...@googlegroups.com
On Thu, Nov 14, 2019 at 6:58 PM Александр Гурьянов <caii...@gmail.com> wrote:
>
> > i.e. is asm.js really faster than wasm2js on that platforms where you *need* to run JS?
> If browser didn't support asm.js then plain js have same performance
> level. But for sure, if browser support asm.js, then asm.js have much
> much better performance.
> Regarding to you question, I understand your point, but as js-dos
> maintainer I should provide must optimized version for each
> environment (e.g. wasm, asm.js).
>
> Form real use case, I only used asm.js for fallbacking ios safari,
> because sometimes it can't start wasm version with "out of execution
> memory" error (not js-dos case).
>
And do you see a noticeable difference in performance between plain JS
>
> > i.e. is asm.js really faster than wasm2js on that platforms where you *need* to run JS?
> If browser didn't support asm.js then plain js have same performance
> level. But for sure, if browser support asm.js, then asm.js have much
> much better performance.
> Regarding to you question, I understand your point, but as js-dos
> maintainer I should provide must optimized version for each
> environment (e.g. wasm, asm.js).
>
> Form real use case, I only used asm.js for fallbacking ios safari,
> because sometimes it can't start wasm version with "out of execution
> memory" error (not js-dos case).
>
and asm.js on iOS safari? i.e. do iOS safari continue to support and
optimize "use asm"?
Hopefully that "out of execution memory" issue can and will be
addressed in safari. Do you know why you might be seeing this? Do
you have a lot of code? Are you instantiating a lot of module?
> memory
> Anyway, my feedback is that wasm+asynicify version is most performant
> and stable version, that should be used most time.
> I don't know why but it even more faster then wasm no async version.
That seems amazing/strange. How are you measuring performance? I
> and stable version, that should be used most time.
> I don't know why but it even more faster then wasm no async version.
wouldn't be surprised if you saw increased responsiveness.
Александр Гурьянов
Nov 17, 2019, 7:45:11 PM11/17/19
to emscripte...@googlegroups.com
> Hopefully that "out of execution memory" issue can and will be addressed in safari. Do you know why you might be seeing this?
This happens when wasm binary is bigger then some threshold, like
>5Mb. Depends on iPhone version. This never happens with dosbox,
because it's size <3Mb, but regularly with some other projects (for
example any Unity project).
> Are you instantiating a lot of module?
--
Found that my measuring system is incorrect. I will fix it asap, and
return with results soon.
сб, 16 нояб. 2019 г. в 00:49, 'Sam Clegg' via emscripten-discuss
Александр Гурьянов
Nov 18, 2019, 11:16:21 AM11/18/19
to emscripte...@googlegroups.com
Ok, now I fix my test and do some benchmarks.
--
From: https://js-dos.com/#js-dos-622-preformance
--
To measure performance I used variant of Dhrystone 2 Test. Original version used clock() to calculate delta time. Which is good for real pc, but does not very accurate for dosbox emulator.
When clock() call happend modifed version send `~>dtime` marker which intercepted by test page and used to calculate delta time with performance.now() from browser.
Source code of test https://github.com/caiiiycuk/js-dos/tree/6.22/programms/dhry2.
Basically this test produce a lot of int operations and measure amount of operations (Dhrystones) produced per second. Output is a VAX MIPS RATING which is Drhystones per second divided by 1757 (is as DEC VAX 11/780 result).
You can run this test (https://js-dos.com/6.22/examples/?dhry2) for your PC, change variant and see how different implementations affects performance.
--
From: https://js-dos.com/#js-dos-622-preformance
--
To measure performance I used variant of Dhrystone 2 Test. Original version used clock() to calculate delta time. Which is good for real pc, but does not very accurate for dosbox emulator.
When clock() call happend modifed version send `~>dtime` marker which intercepted by test page and used to calculate delta time with performance.now() from browser.
Source code of test https://github.com/caiiiycuk/js-dos/tree/6.22/programms/dhry2.
Basically this test produce a lot of int operations and measure amount of operations (Dhrystones) produced per second. Output is a VAX MIPS RATING which is Drhystones per second divided by 1757 (is as DEC VAX 11/780 result).
You can run this test (https://js-dos.com/6.22/examples/?dhry2) for your PC, change variant and see how different implementations affects performance.
Host for this run is Ubuntu 19.10 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz. Host result for same test but with native dosbox is 125.
Current version is ~10 times slower then native dosbox. Optimal version to use is a asyncify (wdosbox.js) whice have similar performance as a nosync version (wdosbox-nosync.js) but much more stable.
ASM.JS versions emterpJs (wdosbox-emterp.js) and nosyncJs (wdosbox-nosync.js) have good performance only in Firefox, other browsers seems does not do any optimization and performance is much worse.
--
So, as result there is no need to use ASM.JS anymore.
пн, 18 нояб. 2019 г. в 07:44, Александр Гурьянов <caii...@gmail.com>:
Reply all
Reply to author
Forward
0 new messages