Hello Alon and Floh,

Thank you so much for the reply.

Just to give a brief introduction about the extension, it allows to view 
and edit the Office documents. We use 3 different wasm modules (Word, Sheet 
and Point), of which only one makes use of exceptions.
Yes, we are investigating the performance differences using the profiling 
traces. Till now followings are the findings.

   1. In wasm, if File I/O is done on another pthread instead of main 
   application thread, its slower. This issue 
   <https://github.com/emscripten-core/emscripten/issues/3922> on 
   Emscripten also talks about it. After shifting the File I/O logic to `main 
   application thread` and separating `main application thread` from the `main 
   browser thread`, performance improved in the wasm. However, still slower by 
   30% w.r.t. NaCl.
   2. As you mentioned, yes, exception handling is slower in wasm compared 
   to NaCl. Functions like `get` and `invoke_*` (from Emscripten's glue code, 
   the .js file) found to be time consuming. After disabling exceptions, yes, 
   the performance of wasm improves and almost matches with that of NaCl. 
   However, it will make the extension unstable. So, can't consider this as a 
   solution.
   I haven't tried `-fwasm-exceptions` yet. I will try it too. And keep you 
   posted.
   3. The extension uses `pixman` library which makes use of SSE 
   instructions. Till now, I didn't use flags `-msimd128` and `-msse`. I 
   will try and let you know.
   

Regards,
Amol


On Thursday, May 6, 2021 at 7:50:29 PM UTC+5:30 Floh wrote:

> PS: FWIW the difference you're seeing is quite similar to the difference 
> between a native and wasm version of my 8-bit home computer emulators. For 
> instance on my mid-2014 13 MBP, the C64 emulator's (
> https://floooh.github.io/tiny8bit/c64-ui.html) frame duration is between 
> 4 and 5ms in the native version, and between 6 and 7ms in the WASM version 
> (in Chrome). The emulator code is fairly straightforward single-threaded 
> portable C code with heavy bit twiddling on 64-bit integers.
>
> On Thursday, 6 May 2021 at 16:12:51 UTC+2 Floh wrote:
>
>> >  Right now, Emscripten only supports building 32 bit .wasm. Whereas, 
>> .nexe is 64 bit.
>>
>> Note that the 32 in WASM32 is only about the pointer size, it has 
>> "proper" 64-bit integers, only pointers (and thus the maximum heap size) 
>> are 32 bits. Theoretically this should even yield better performance than 
>> 64-bit pointers.
>>
>> "long double" seem to be 128 bit floating point numbers, I don't think 
>> that those have much relevance. Regular doubles (64-bits wide) are 
>> supported natively by WASM.
>>
>> 30% performance difference doesn't sound all that surprising TBH and 
>> might result from low level code generation differences between the WASM 
>> and PNaCl LLVM backends (for instance differences in register allocation, 
>> or calling conventions).
>>
>> On Tuesday, 4 May 2021 at 15:27:50 UTC+2 Amol Wagh wrote:
>>
>>>
>>> Hello All,
>>>
>>> We have a chrome extension written in C++ and Javascript. Recently, 
>>> changes are done to make use of WebAssembly module instead of NaCl module.
>>> However, performance of WebAssembly found to be slower, on an avg by 30% 
>>> and despite using `-O3`, than the NaCl's performance.
>>> Emscripten compiler, v2.0.7, is used to prepare the .wasm. Whereas for 
>>> .nexe, the C++ code is compiled using `pnacl-clang++` compiler. Later 
>>> `pnacl-transalte` is used to generate the .nexe file. (x86_64 arch).
>>>
>>> OS and Compiler details are as follows. 
>>> NaCl SDK having `Pepper 50`
>>> Emscripten SDK version 2.0.7
>>> Ubuntu 18.04.5 LTS
>>> Chrome version 88.0.4324.182 (64-bit)
>>> Processor : Intel® Core™ i5-5200U CPU @ 2.20GHz × 4
>>>
>>> My concern is -
>>> Right now, Emscripten only supports building 32 bit .wasm. Whereas, 
>>> .nexe is 64 bit. Are the two executable right candidates for the 
>>> performance comparison?
>>> There might be differences at several places.
>>> e.g. As mentioned in the design spec 
>>> <https://github.com/WebAssembly/design/blob/master/CAndC%2B%2B.md#platform-features>
>>>  
>>> of WebAssembly, `long double` are software-emulated.
>>> Note that, I can build 32 bit nexe. However, can't use it in 64 bit 
>>> Chrome. Following error occurs in that case.
>>> NaCl module load failed: ELF file for wrong architecture.
>>>
>>> Regards,.
>>> Amol
>>>
>>
-- 
This e-mail, including any attached files, may contain confidential and 
privileged information for the sole use of the intended recipient. Any 
review, use, distribution, or disclosure by others is strictly prohibited. 
If you are not the intended recipient (or authorized to receive information 
for the intended recipient), please contact the sender by reply e-mail and 
delete all copies of this message.










-- 
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/86f5dc20-c13c-4297-8747-1f0c758d34dbn%40googlegroups.com.

Reply via email to